nicht angemeldet
Eine Art DynDns ...??
0 
Matthias Apsel
0 0 0 0 0 0 0 0 0 0 0 0 0 0 DynDNS-Gefummel ist hier wohl die falsche Lösung
0 
Julius
Eine Art DynDns ...??
TabellenkalkHallo,
ich habe ein System vor mir das wie folgt aufgebaut ist.
-
Einen Webserver ("Master") der eine feste IP hat. (Zugriff über Internet)
-
ca. 15-20 Webserver ("Slave" .. teilweise Internet/Intranet) die per scp eine vorgefertigte index.html auf den Webserver ("Master") kopieren. Die index.html die kopiert wird, beinhaltet immer die aktuelle IP mit der auf den Webserver("Slave") zugegriffen werden kann.
index.html:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title></title>
</HEAD>
<FRAMESET ROWS="100%" FRAMEBORDER="0" FRAMESPACING="0">
<FRAME NAME="ALL" SRC="http://123.123.123.123/" Scrolling="AUTO">
<noframe>Leider kann diese Seite ohne Frame-Unterstützung nicht benutzt werden</noframe>
</FRAMESET>
<BODY></BODY>
</HTML>
Diese index.html wird ins jeweilige "/srv/www/htdocs/slavename/" Verzeichnis kopiert. d.h. "/srv/www/htdocs/slavename_1/index.html" (in der index.html IP von Webserver-Slavename_1) "/srv/www/htdocs/slavename_2/index.html" (in der index.html IP von Webserver-Slavename_1) "/srv/www/htdocs/slavename_x/index.html" (in der index.html IP von Webserver-Slavename_1)
Über die feste IP-Adresse "http:w.x.y.z/slavename_1/" kann auf die externen Webserver ("Slavename_1") zugegriffen werden. Auf den externen Webservern stehen nur Beschreibungen und Anleitungen ... nichts wichtiges.
Der Systemaufbau soll möglichst bestehen bleiben (nicht meine Idee ..) Ich soll mir nun überlegen, wie ich den Zugriff auf https umstelle. Mit einem selbst erzeugten Zertifikat habe ich das Problem, das jedesmal wenn sich die öffentliche IP der Webserver ("Slave") ändert, ich das Zertifikat neu bestätigen muß. Ein "bezahltes" Zertifikat scheidet aus, da auch nicht alle Rechner Internetzugang haben.
Meine Idee ..... Ich habe die IP-Adresse jedes Rechners. Kann ich diese auf dem Webserver ("Master") nicht so benutzen, wie ein DynDns Server. Damit müsste ich bei veränderter IP das "eigene" Zertifikat nicht immer bestätigen ("Verbindung ist nicht sicher ....usw." Dialog)
Hört sich etwas verwirrend an. Ich hoffe es war verständlich erklärt.
Eine einfache Anleitung einen DynDns Server nachträglich auf dem Webserver ("Master") zu installieren, habe ich noch nicht gefunden. Jede Beschreibung unterscheidet sich extrem von der anderen. Daher bin ich mir nicht sicher, ob ich das riskieren soll.
vielen Dank im voraus
henry
-
Hallo henry,
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <title></title> </HEAD> <FRAMESET ROWS="100%" FRAMEBORDER="0" FRAMESPACING="0"> <FRAME NAME="ALL" SRC="http://123.123.123.123/" Scrolling="AUTO"> <noframe>Leider kann diese Seite ohne Frame-Unterstützung nicht benutzt werden</noframe> </FRAMESET> <BODY></BODY> </HTML>hat zwar mit deinem Problem nichts zu tun, aber (und beachte die Wahl der Zeitform)
- falscher doctype, es gab einen eigenen für framesets
- eine Angabe zur Zeichenkodierung fehlt
- man brauchte kein body-Element in frameset-Seiten
- das Element hieß noframes
Kann man eigentlich die Frame-Unterstützung ausschalten?
Bis demnächst
Matthias -
Eine einfache Anleitung einen DynDns Server nachträglich auf dem Webserver ("Master") zu installieren, habe ich noch nicht gefunden. Jede Beschreibung unterscheidet sich extrem von der anderen. Daher bin ich mir nicht sicher, ob ich das riskieren soll.
Üblich ists, via HTTP(s) die Updates der Zonendatei anzutriggern. Die IP ergibt sich aus REMOTE_ADDR oder wird optional als Parameter like ip=255.255.255.255 mitgesendet. Der Domain-Name wird entweder auch als Parameter gesendet oder im Benutznamen (Authorization: Basic) kodiert.
So kriegt ein dafür eingesetzter WebServer die Daten fürs Update der Zonendatei (A-Record), incrementiert serial und macht ein ndc reload, fertig (Webserver + Nameserver auf einer Machine).
Die DynDNS-Clients machen nur noch Requests, entweder wenn sie selbst einer Änderung der IP-Adresse festgestellt haben oder der Webserver stellt das für den Client fest.
Nichts Weltbewegendes, kriegst hin, musts nur Wolle ;)
-
Tach,
Eine einfache Anleitung einen DynDns Server nachträglich auf dem Webserver ("Master") zu installieren, habe ich noch nicht gefunden. Jede Beschreibung unterscheidet sich extrem von der anderen. Daher bin ich mir nicht sicher, ob ich das riskieren soll.
Üblich ists, via HTTP(s) die Updates der Zonendatei anzutriggern. Die IP ergibt sich aus REMOTE_ADDR oder wird optional als Parameter like ip=255.255.255.255 mitgesendet. Der Domain-Name wird entweder auch als Parameter gesendet oder im Benutznamen (Authorization: Basic) kodiert.
ich würde die Updates gleich über SSH regeln (Public Key Encryption statt Passworten); für jeden Client einen User mit einem Script als Login-Shell, dass die IP ausliest und das entsprechende Zone-Script updated.
mfg
Woodfighter-
ich würde die Updates gleich über SSH regeln (Public Key Encryption statt Passworten); für jeden Client einen User mit einem Script als Login-Shell, dass die IP ausliest und das entsprechende Zone-Script updated.
Und ich würde mich immer für eine Lösung entscheiden, die unter Berücksichtigung aller Faktoren am zweckmäßigsten ist.
-
ich würde die Updates gleich über SSH regeln (Public Key Encryption statt Passworten);
Klingt wie eine gute Idee. Ist definitiv auch eine.
Anmerkungen:
1.) Aber in dem Fall, das später eventuell andere Mechanismen unterstützt werden sollen (z.b. wenn lokale Fritzboxen den Internetzugang für die Rechner herstellen) sollte man die Idee mit dem HTTP[S] unbedingt im Auge behalten, weil die Boxen natürlich "wissen", wann die einen Reconnect ausgeführt haben. Das macht andere schwierig einzurichtende und weniger perfekte Mechanismen (cronjobs) obsolet.
2.) Wenn per ssh, dann aufpassen: Auf dem DynDNS-Server einen sehr rechtlosen Benutzer einrichten, der das Skript zum Ändern des DNS-Eintrages gleich als Shell hat...
-
-
-
Tach,
Ich soll mir nun überlegen, wie ich den Zugriff auf https umstelle. Mit einem selbst erzeugten Zertifikat habe ich das Problem, das jedesmal wenn sich die öffentliche IP der Webserver ("Slave") ändert, ich das Zertifikat neu bestätigen muß.
ja, wechselnde Hostnamen und TLS sind nicht kompatibel (den hier nicht zutreffende Spezialfall Wildcard mal ausgenommen).
Ein "bezahltes" Zertifikat scheidet aus, da auch nicht alle Rechner Internetzugang haben.
Dieses Argument verstehe ich nicht, Internetzugang ist für ein Zertifikat einer CA nicht nötig.
Ich habe die IP-Adresse jedes Rechners. Kann ich diese auf dem Webserver ("Master") nicht so benutzen, wie ein DynDns Server. Damit müsste ich bei veränderter IP das "eigene" Zertifikat nicht immer bestätigen ("Verbindung ist nicht sicher ....usw." Dialog)
Eine alternative Möglichkeit als DynDNS wäre ein Reverse-Proxy, der einen SSH-Tunnel nutzt, um mit den Clients zu sprechen (dann kann man sich den Framekram auch gleich sparen). AutoSSH hilft dabei, dass die Tunnel dauerhaft existieren.
Eine einfache Anleitung einen DynDns Server nachträglich auf dem Webserver ("Master") zu installieren, habe ich noch nicht gefunden. Jede Beschreibung unterscheidet sich extrem von der anderen. Daher bin ich mir nicht sicher, ob ich das riskieren soll.
Wenn du keine Erfahrung mit dem Betreiben eines Nameservers hast, solltest du auch erstmal die Finger davon lassen.
mfg
Woodfighter -
Hi,
benutzt du das kostenlose SSL für Jedermann, das es schon geben soll?
Hab zur Zeit keinen Server - würde mich aber auch interessieren, obs klappt.Viele Grüße aus LA
ralphi--
"Nicht alles was einfach ist, ist genial, aber alles was genial ist, ist einfach" - Albert E.-
benutzt du das kostenlose SSL für Jedermann, das es schon geben soll?
Hab zur Zeit keinen Server - würde mich aber auch interessieren, obs klappt.Geht prima. Inklusive Autoupdate aller 2 Monate via cronjob. (Das Zertifikat ist nur 90 Tage gültig.)
-
-
Hast du denn überhaupt Zugriff auf die DNS-Server Deiner Domain?
Wenn Du dann die einzelnen Zugänge noch per Fritzbox herstellt, dann könntest Du die Fritzboxen und AVM die DNS-Updates erledigen lassen (hast dann "schöne" Namen wie zab459cc77opy6se.myfritz.net) und im eigenen DNS einfach CNAMES anlegen:
Auszug aus: db.example.org:
... frankfurt.example.org. IN CNAME zab459cc77opy6se.myfritz.net. hamburg.example.org. IN CNAME glogf3j5d6k2kl56.myfritz.net. ...-
Hallo,
erst einmal Danke für die Info's.
- von den Webservern ("Slave") wird per scp mit public key die index.html übertragen. Das läuft jetzt schon so.
- Das jemals eine Fritzbox die Funktion Dyndns Client übernimmt, wage ich zu bezweifeln.
- Eine cronjob Lösung der mir alle 10-30 Minuten die aktuelle IP an den Webserver ("Master") kopiert hat ja die letzten Jahre auch problemlos funktioniert. Ist sicher nicht 1000% ig ... aber geht.
- Alles sind Linuxsystem, an denen ich auch Scripte/Programme zur manipulation programmieren kann.
- Ich habe überall root-Rechte ... auch das ist kein Problem.
Wenn das mit der Installation eines DynDns Servers wirklich so schwierig ist, hätte ich noch eine Idee. Könnte ich nicht am Webserver ("Master") die /etc/hosts mit den dynamischen IP-Adressen manipulieren ?
Wie gesagt .... eine Idee ;-)
Danke piet-
Könnte ich nicht am Webserver ("Master") die /etc/hosts mit den dynamischen IP-Adressen manipulieren ?
Freilich, musst die hosts halt nur auf ALLE Rechner verteilen. Wenn da ehe ne Softwareverteilung zugange ist, ein Aufwasch.
-
Hallo,
Könnte ich nicht am Webserver ("Master") die /etc/hosts mit den dynamischen IP-Adressen manipulieren ?
Freilich, musst die hosts halt nur auf ALLE Rechner verteilen. Wenn da ehe ne Softwareverteilung zugange ist, ein Aufwasch.
Ich dachte ich manipuliere nur die hosts am Webserver ("Master") Wenn am Webserver("Master") die index.html ankommt starte ich mein Script manipuliere die hosts und lösche die index.html z.B.
slave IP master ip https://123.123.123.123 http:90.90.90.90/slavename_1 https://222.222.222.222 http:90.90.90.90/slavename_2würde das so funktionieren ? Mit IP-Adressen und nur Namen ist es mir klar, aber hier bin ich nicht sicher. Eine Kombination aus ip und Namen hatte ich nocht nicht ;-)
Gruß
-
Wenn am Webserver("Master") die index.html ankommt starte ich mein Script manipuliere die hosts und lösche die index.html z.B.
slave IP master ip https://123.123.123.123 http:90.90.90.90/slavename_1 https://222.222.222.222 http:90.90.90.90/slavename_2würde das so funktionieren ?
Nein. Und zwar schon deshalb nicht, weil dieses keine gültige Hosts-Datei ist. Ein
man 5 hostshätte Dir weiter geholfen.
-
-
-
3. Eine cronjob Lösung der mir alle 10-30 Minuten die aktuelle IP an den Webserver ("Master") kopiert hat ja die letzten Jahre auch problemlos funktioniert. Ist sicher nicht 1000% ig ... aber geht.
Je nach Aussehen der URL Deines iframes kann sich der Client dann aber auch 10-30 Minuten lang mit seinem Request an den falschen Server und ergo auch einen Honigtopf wenden und mit seiner öffentlichen IP postwendend (ergo) auf Blocklist.de landen.
Dann herauszubekommen, warum einige Kunden (bzw. alle Teilnehmer an deren Netzwerk) plötzlich Probleme mit der einen oder anderen Netzwerkverbindung haben, könnte schwierig werden.
-
2. Das jemals eine Fritzbox die Funktion Dyndns Client übernimmt, wage ich zu bezweifeln.
Nun ja. Bei dem präsentiertem Problem wäre Fritzbox, Dyndns und Portweiterleitung eine naheliegende Lösung und zudem auch Verbesserung. Es muss ja auch keine Fritzbox sein, andere Router oder ISPs können sowas auch. Oder willst Du damit sagen, dass hier eine derart extreme Diskrepanz zwischen der IFRAME Lösung, der bisherigen Methode und den Netzwerkzugängen der Standorte besteht? Immerhin hast noch immer kein Wort darüber verloren wie denn das Netz aufgebaut ist und warum Du Dyndns benötigst.
Genau davon hängt aber ab, welche der vielen Möglichkeiten die beste ist.
Ich z.B. würde dazu neigen, statt die abzurufende Information auf einem "Server" hinter der dynamischen IP bereitzuhalten, diese Information statt der IP auf den echten Server zu übertragen. Das hätte dann den Vorteil, dass die IP nicht öffentlich bekannt wird und schließt einen Angriffsvektor. So wie Deine Fragen und Äußerungen in meinen Ohren klingen wäre das von erheblichen Vorteil.
-
Hallo,
2. Das jemals eine Fritzbox die Funktion Dyndns Client übernimmt, wage ich zu bezweifeln.
Nun ja. Bei dem präsentiertem Problem wäre Fritzbox, Dyndns und Portweiterleitung eine naheliegende Lösung und zudem auch Verbesserung. Es muss ja auch keine Fritzbox sein, andere Router oder ISPs können sowas auch. Oder willst Du damit sagen, dass hier eine derart extreme Diskrepanz zwischen der IFRAME Lösung, der bisherigen Methode und den Netzwerkzugängen der Standorte besteht? Immerhin hast noch immer kein Wort darüber verloren wie denn das Netz aufgebaut ist und warum Du Dyndns benötigst.
Genau davon hängt aber ab, welche der vielen Möglichkeiten die beste ist.
Wie im ersten Tread geschrieben, benötige ich, so glaube ich, einen dyndns-Server.
Hintergrund: Das System soll auf https umgestellt werden. Soweit so gut. Ich erstelle jeweils ein eigenes Zertifikat und bei der ersten Anwahl muss ich das "unsichere Zertifikat" einmal bestätigen. Da ich aber dynamische IP-Adressen habe muss ich jedesmal das Zertifikat bestätigen, wenn sich die IP ändert.
Also dachte ich an einen Dyndns Server, den ich auf den vorhandenen Webserver ("Master") installiere. Dieser hat Zugang zum Internet und den öffentlichen Webservern ("Slave") genauso aber zu den im Intranet verteilten Webservern("Slave"). Diese sind wiederum tatsächlich im Intranet oder per vpn im Intranet gelandet. Mit einem dyndns Somit muss ich das Zertifikat nur beim ersten mal bestätigen. Ein Bezahl-Zertifikat will man nicht. Ein 90Tage Zertifikat ist auch nicht das wahre. Eine neue "beta" mit kostenlosen Zertifikaten werde ich sicher nicht nutzen.
Sollten noch Fragen offen sein bitte nur raus damit ;-)
-
Also dachte ich an einen Dyndns Server, den ich auf den vorhandenen Webserver ("Master") installiere.
Hm. Der "Dyndns Server" muss aber mindestens einen DNS-Server "manipulieren". Der oder die DNS-Server [muss|müssen] dann [der|die]jenigen[n] sein, [dem|denen] alle Clients bei der Namensauflösung glauben.
Bist Du Dir wirklich bewusst, was Du Dir auf den Buckel holst?
-
Hallo,
10x gelesen .... doch nicht verstanden ;-) Kannst Du es anders erklären, eventuell Beispiel ?
-
10x gelesen .... doch nicht verstanden ;-) Kannst Du es anders erklären, eventuell Beispiel ?
Du überträgst bisher eine IP an den Webserver welche in das Frameset in der index.html eingebaut wird (oder ist). Übertrage statt dessen die Daten/Webseiten selbst auf den Webserver. Freilich kannst auch via sshfs oder nfs Freigaben Deiner "slaves" auf dem Server mounten und dann aus Sicht des Apache ein Verzeichnis benutzen. Das erzeugt aber sehr wahrscheinlich unnötig Netzlast.
Was von alledem möglich und erst recht was vorteilhaft ist hängt von Umständen ab, die Du nicht erwähnt hast. Insbesondere fehlt mir auch jede Kenntnis darüber, was denn im IFRAME angezeigt wird, wie oft sich das ändert und was Du auf allen beteiligten ("master" , "slaves", "clients" - die mit dem Webbrowser) Rechnern selbst darfst oder veranlassen kannst.
Begriffe:
- "master": der Webserver mit den index.html, welche das Frameset enthalten.
- "slaves": Rechner mit einem Webserverm welche die Inhalte der FRAMES bereithalten.
- "clients": Rechner mit Webbrowser.
Fragen:
- Was davon (Begriffe) steht wo und was davon ist über welche IP (öffentliche, private) erreichbar?
- Was enthalten die "slaves" und wie oft ändern sich diese Daten? Sind es "Echtzeit-Daten" oder Messdaten?
- Wo ist "https" nötig?
-
Hallo,
Du hast Recht .... hier etwas bessere Beschreibung
Begriffe:
- "master": der Webserver der eine statische IP hat und auf den die index.html kopiert werden, welche das Frameset haben. (öffentlich)
- "slaves": mehrere Rechner mit einem Webserver welche die Inhalte der FRAMES bereithalten. Von hier werden die index.html generiert und auf den "master" kopiert. dynamische IP (meistens öffentlich, 2x private)
- "clients": Begriff kommt in meiner Erklärung nicht vor.
Fragen:
- Was davon (Begriffe) steht wo und was davon ist über welche IP (öffentliche, private) erreichbar?
- "master" öffentlich mit statischer IP
- "slave" öffentlich (plus 2 x private) mit dynamischer IP
- Was enthalten die "slaves" und wie oft ändern sich diese Daten? Sind es "Echtzeit-Daten" oder Messdaten?
- Auf den "slaves" läuft ein kompletter Webserver mit Messdatenerfassung. Dynamischen Webseiten, Ajax, Datenbank usw.
- Wo ist "https" nötig?
- Der Aufruf der "slaves" erfolgt ja über das Verzeichnis "http://statische_ip_master/slavename/" in dem die index.html steht. In der index.html soll später
<FRAME NAME="ALL" SRC="https://123.123.123.123/" Scrolling="AUTO">stehen.
-
- Auf den "slaves" läuft ein kompletter Webserver mit Messdatenerfassung. Dynamischen Webseiten, Ajax, Datenbank usw.
Königsweg:
Die "slaves" übertragen die Messdaten auf den "master". Dafür gibt es wunderschöne und auch sichere Möglichkeiten ohne die Unwägbarkeiten (und Ausfallraten) eines komplizierten, verteilten und selbst von Experten (zu viele Einzelgebiete!) kaum beherrschten Systems wie Du es bisher anstrebst. Grafiken bzw. Diagramme können auf den Slaves vorberechnet werden oder man überlässt dieses mit HTML5/SVG den Webbrowsern um den Server zu entlasten.
https bzw. ssh arbeitet dann zwischen clients und server und slaves und server (Link zu den hier und dafür von mir gesetzten Begriffsdefinitionen). Eine Verbindung zwischen den clients und den slaves findet dann nicht mehr statt.
Ich kannte mal einen genialen angehenden Maschinenbauingenieur, dessen Zeug jetzt Mercedes im Antriebsstrang verbaut. Der hatte als Motto "Einfach, einfach einfach!"
Und das hat was für sich.
-
Hallo,
Die "slaves" übertragen die Messdaten auf den "master". Dafür gibt es wunderschöne und auch sichere Möglichkeiten ohne die Unwägbarkeiten (und Ausfallraten) eines komplizierten, verteilten und selbst von Experten (zu viele Einzelgebiete!) kaum beherrschten Systems wie Du es bisher anstrebst. Grafiken bzw. Diagramme können auf den Slaves vorberechnet werden oder man überlässt dieses mit HTML5/SVG den Webbrowsern um den Server zu entlasten.
Ich müsste eine komplett neue Menüstruktur am Webserver ("Master") erstellen. Zugriff auf Datenbanken um die Diagramme zu erstellen, cgi-scripte ändern, Webseiten die gleiche Namen haben verändern oder alles dynamisieren. Oder aber für jeden einen virtuellen Host anlegen. Ich denke, das vom Zeitaufwand dies sicher mehr kostet und mehr Gefahren (Fehler) bringt als gedacht. Und alles unter laufendem Betrieb, oder einem "langen" Wochenende.
Wie gesagt dyndns war ja nur eine Idee. Das aktuelle System mit iframe und index.html funktioniert, sicher nicht ideal, seit Jahren.
Ich will nur https einbauen und verhindern das beim Zugriff jedesmal das Zertifikat neu bestätigt werden muss, wen sich die dynamische ip ändert.
Einfach, einfach, einfach ist ganz bestimmt auch mein Slogan ;-)
Da der Zugriff ja nur über den Webserver ("master") erfolgt, wie ja jetzt auch, könnte ich dies nicht doch anders lösen.
Ich möchte nochmals die Idee mit /etc/hosts aufgreifen ... "Strohhalm" /etc/host
Es war von mir nur ein Beispiel, das man in die /etc/hosts kein http/https schreibt ist mir schon klar.
Wenn nicht, dann lasse ich die "Arbeiten" sein, bestehe auf ein "bezahl" - Zertifikat oder statische IP-Adressen.
-
Ich möchte nochmals die Idee mit /etc/hosts aufgreifen ... "Strohhalm"
Das wird nichts. Damit begibst Du Dich in die Anfangszeit von Unix mit TCP/IP zurück und müsstest die hosts-Datei (z.B. mit dem eben so alten NIS) auf alle Clients (also die Rechner mit dem Webbrowser) verteilen!
Wenn nicht, dann lasse ich die "Arbeiten" sein,
bestehe auf ein "bezahl" - Zertifikat
... welches Dich nicht weiter bringt als ein kostenloses ...
oder statische IP-Adressen.
Eine Frage ist immer noch nicht beantwortet: Wieso haben einige der Slaves dynamische IP-Adressen? Wer verwaltet das? Etwa die eigene Firma, weil die "Slaves" am DHCP hängen? Dann ist der schlimmste Teil des Problems doch in "Nullkommanichts" behoben?
-
Hallo,
Eine Frage ist immer noch nicht beantwortet: Wieso haben einige der Slaves dynamische IP-Adressen? Wer verwaltet das? Etwa die eigene Firma, weil die "Slaves" am DHCP hängen? Dann ist der schlimmste Teil des Problems doch in "Nullkommanichts" behoben?
dynamisch ist die öffentliche IP-Adresse. Nur zwei Rechner sitzen im Intranet und bekommen die IP vom DHCP.Das ist sicher das kleinste Problem ;-)
Gruss
-
Das ist sicher das kleinste Problem ;-)
Das nächste Problem wäre der DNS-Cache des Browsers. Hier der Hinweis von MS zum IE/Edge. Andere Browser machen das auch. Grund für das eigentlich regelwidrige Verhalten: Harter Wettbewerb um gefühlte Performancevorteile.
Das sind also ziemlich viele kleine Probleme mit insgesamt sehr vielen und irre umständlichen Lösungen.
Es geht deshalb immer wieder zurück zum Königsweg. Alles auf den Server mit der fixen IP schaufeln.
-
Tach,
Es geht deshalb immer wieder zurück zum Königsweg. Alles auf den Server mit der fixen IP schaufeln.
je nach Datenvolumen, Aufwand und Aktualitätsbedürfnis, würde ich weiterhin meinen Alternativvorschlag vorziehen.
mfg
Woodfighter-
je nach Datenvolumen, Aufwand und Aktualitätsbedürfnis, würde ich weiterhin meinen Alternativvorschlag vorziehen.
Das ist eine durchaus akzeptable, unter Beachtung und Wichtung der von Dir genannten Umstände womöglich sogar die vorzuziehende Lösung. Allerdings hast Du im von Dir verlinkten Beitrag durch die Blume auch gesagt warum diese sich im konkreten Einzelfall als unbeherrschbar erweisen könnte.
-
Tach,
je nach Datenvolumen, Aufwand und Aktualitätsbedürfnis, würde ich weiterhin meinen Alternativvorschlag vorziehen.
Das ist eine durchaus akzeptable, unter Beachtung und Wichtung der von Dir genannten Umstände womöglich sogar die vorzuziehende Lösung. Allerdings hast Du im von Dir verlinkten Beitrag durch die Blume auch gesagt warum diese sich im konkreten Einzelfall als unbeherrschbar erweisen könnte.
ich verstehe nicht, was du mit unbeherschbar meinst.
mfg
Woodfighter-
ich verstehe nicht, was du mit unbeherschbar meinst.
Ich hätte es jetzt verstanden, wenn der TO dieses geäußert hätte.
-
Tach,
ich verstehe nicht, was du mit unbeherschbar meinst.
Ich hätte es jetzt verstanden, wenn der TO dieses geäußert hätte.
ah, danke, das hilft mir jetzt natürlich enorm weiter. Mein Unverständnis ruht daher, dass ich die angesprochene Technik ohne Probleme aktiv nutze und diese demensprechend nicht als unbeherschbar einschätzen kann.
mfg
Woodfighter-
ah, danke, das hilft mir jetzt natürlich enorm weiter.
Die durchsagte Blume war aber schon eine sehr kleine. Bitte künftig aufmerksamer lesen.
-
Tach,
ah, danke, das hilft mir jetzt natürlich enorm weiter.
Die durchsagte Blume war aber schon eine sehr kleine. Bitte künftig aufmerksamer lesen.
falls es dir nicht darum geht verstanden zu werden, bist du definitiv auf dem richtigen Weg.
mfg
Woodfighter-
falls es dir nicht darum geht verstanden zu werden
Das trifft zwar in dieser Allgemeinheit nicht zu aber man kann das durchaus so annehmen.
-
Tach,
falls es dir nicht darum geht verstanden zu werden
Das trifft zwar in dieser Allgemeinheit nicht zu aber man kann das durchaus so annehmen.
gut, dann kann man die Aussage ja einfach auf dem Müllplatz für unsinnige Aussagen liegn lassen.
mfg
Woodfighter-
gut, dann kann man die Aussage ja einfach auf dem Müllplatz für unsinnige Aussagen liegn lassen.
Für den, der es nicht verstanden hat, gilt:
"nicht verstandende Aussage" == "unsinnige Aussage"Für alle anderen:
"von manchen nicht verstandende Aussage" === "eben diesen unsinnig erscheinende Aussage"Es war für mich nicht absehbar, dass Du das nicht verstehst. Für Dich also: Man kann einem gewissen Theo durchaus eine Lösung vorschlagen, aber wenn es mehrere gibt, dann sollte man eine wählen mit welcher der Theo voraussichtlich Erfolg haben wird oder wenigstens kann.
Und man muss auch nicht alles so sagen, dass es die Allgemeinheit (also jeder) versteht. Ich dachte, das hättest Du verstanden. Es ist halt schwierig in einem Forum die sprachliche und/oder soziale Intelligenz der Teilnehmer einzuschätzen.
-
Tach,
gut, dann kann man die Aussage ja einfach auf dem Müllplatz für unsinnige Aussagen liegn lassen.
Für den, der es nicht verstanden hat, gilt:
"nicht verstandende Aussage" == "unsinnige Aussage"nein, die Aussage wurde von mir als unsinnig bewertet, weil du nicht willens oder in der Lage warst, sie trotz Nachfragens verständlich zu formulieren. Das kann entweder bedeuten, dass jemand Begriffe falsch verwendet und sie deshalb keinen Sinn ergeben, wie es z.B. bei @pl häufiger der Fall ist, dass jemand nur herumstänkern möchte oder dass der Autor selber nicht weiß, was er meint.
Es war für mich nicht absehbar, dass Du das nicht verstehst.
Also Kommunikationsswäche auf deiner Seite, dir war bewußt, dass ich deine Antwort nicht verstehen würde und hast ihre Form trotzdem nicht geändert; ich plädiere auf, du wolltest nur rumstänkern.
Für Dich also: Man kann einem gewissen Theo durchaus eine Lösung vorschlagen, aber wenn es mehrere gibt, dann sollte man eine wählen mit welcher der Theo voraussichtlich Erfolg haben wird oder wenigstens kann.
Ok, dann schätzt du meine Lösung als komplizierter ein, als sie es tatsächlich ist. Wäre eine Nachfrage gekommen, hätte ich sicherlich auch noch weiter helfen können, aber ich neige nicht dazu längere Texte ins Forum zu kippen, die dann nicht gelesen werden.
Und man muss auch nicht alles so sagen, dass es die Allgemeinheit (also jeder) versteht.
Nein, aber dann auf Nachfragen zum erklärten Unverständnis nicht sinnvoll zu reagieren, ist für mich kein Zeichen von Überlegenheit.
mfg
Woodfighter-
Also Kommunikationsswäche auf deiner Seite, dir war bewußt, dass ich deine Antwort nicht verstehen würde und hast ihre Form trotzdem nicht geändert;
Unsinn. Dann hätte ich das hier nicht geschrieben:
Das ist eine durchaus akzeptable, unter Beachtung und Wichtung der von Dir genannten Umstände womöglich sogar die vorzuziehende Lösung. Allerdings hast Du im von Dir verlinkten Beitrag durch die Blume auch gesagt warum diese sich im konkreten Einzelfall als unbeherrschbar erweisen könnte.
ich plädiere auf, du wolltest nur rumstänkern.
Das aber nur, weil Du es so verstehen willst.
Mein Satz: "Allerdings hast Du im von Dir verlinkten Beitrag durch die Blume auch gesagt warum diese sich im konkreten Einzelfall als unbeherrschbar erweisen könnte."
bezog sich nämlich auf Deinen:
"Wenn du keine Erfahrung mit dem Betreiben eines Nameservers hast, solltest du auch erstmal die Finger davon lassen."
Die von Dir vorgeschlagene Lösung mit Reverse-Proxy und SSH-Tunnel(n) stellt nämlich Anforderungen an das Wissen und die Erfahrung des potentiellen Betreibers die mit dem Betrieb eines DNS-Servers mindestens vergleichbar sind - soweit sie diese nicht sogar weit übersteigen. Und das dürftest Du wohl eben so genau wissen wie ich.
Wenn man jetzt nicht stur und grundlos annimmt dass ich Dich dissen wollte, dann kommt man sehr schnell darauf, dass ich nicht wollte, dass ein (bestimmter) anderer als Du die Antwort nicht versteht.
Aber irgendwie kam Dir diese Möglichkeit par tout nicht mal in den Sinn, was bei dem einleitenden "Das ist eine durchaus akzeptable, unter Beachtung und Wichtung der von Dir genannten Umstände womöglich sogar die vorzuziehende Lösung" schon sehr ungewöhnlich ist. Du wolltest Dir also par tout die Jacke in der Kindergröße überziehen und hast das Reißen aller Nähte, hier Fehlen jeder Logik in Deinen Schlüssen, überhört. Wutentbrannt wie ein Stier bist Du mit gesenkten Hörnern in eine Richtung gerannt und hast nicht mal mitbekommen, dass dort gar nichts ist, was Du auf die selben nehmen könntest.
Im Austeilen bist ja nicht schlecht. Aber beim Einstecken haperts bei Dir. Du verlierst ja offenbar schon den Verstand, wenn Du nur (und ohne wirkliche Gründe) vermutest, dass jemand Kritik an Dir üben könnte.
Und nicht mal mit "Man kann einem gewissen Theo durchaus eine Lösung vorschlagen, aber wenn es mehrere gibt, dann sollte man eine wählen mit welcher der Theo voraussichtlich Erfolg haben wird oder wenigstens kann." warst Du noch zu stoppen, weil Du nicht mal mehr wusstest, warum Du rennst, geschweige denn woher Du kommst und was Du auf die Hörner nehmen willst...
Wut, mein Freund, ist ein schlechter Ratgeber.
-
Wenn man jetzt nicht stur und grundlos annimmt dass ich Dich dissen wollte, dann kommt man sehr schnell darauf, dass ich nicht wollte, dass ein (bestimmter) anderer als Du die Antwort nicht versteht.
sollte natürlich lauten:
Wenn man jetzt nicht stur und grundlos annimmt dass ich Dich dissen wollte, dann kommt man sehr schnell darauf, dass ich wollte, dass ein (bestimmter) anderer als Du die Antwort nicht versteht.
oder
Wenn man jetzt nicht stur und grundlos annimmt dass ich Dich dissen wollte, dann kommt man sehr schnell darauf, dass ich nicht wollte, dass ein (bestimmter) anderer als Du die Antwort versteht.
In der falschen Fassung ist (eigentlich ersichtlich) ein "nicht" zu viel.
-
Tach,
Also Kommunikationsswäche auf deiner Seite, dir war bewußt, dass ich deine Antwort nicht verstehen würde und hast ihre Form trotzdem nicht geändert;
Unsinn. Dann hätte ich das hier nicht geschrieben:
Das ist eine durchaus akzeptable, unter Beachtung und Wichtung der von Dir genannten Umstände womöglich sogar die vorzuziehende Lösung. Allerdings hast Du im von Dir verlinkten Beitrag durch die Blume auch gesagt warum diese sich im konkreten Einzelfall als unbeherrschbar erweisen könnte.
ich plädiere auf, du wolltest nur rumstänkern.
Das aber nur, weil Du es so verstehen willst.
nein, s/willst/musst/
Mein Satz: "Allerdings hast Du im von Dir verlinkten Beitrag durch die Blume auch gesagt warum diese sich im konkreten Einzelfall als unbeherrschbar erweisen könnte."
bezog sich nämlich auf Deinen:
"Wenn du keine Erfahrung mit dem Betreiben eines Nameservers hast, solltest du auch erstmal die Finger davon lassen."
Die von Dir vorgeschlagene Lösung mit Reverse-Proxy und SSH-Tunnel(n) stellt nämlich Anforderungen an das Wissen und die Erfahrung des potentiellen Betreibers die mit dem Betrieb eines DNS-Servers mindestens vergleichbar sind - soweit sie diese nicht sogar weit übersteigen. Und das dürftest Du wohl eben so genau wissen wie ich.
Die Anforderungen daran sind einfacher und vom Gesichtspunkt der Sicherheitsproblematik deutlich unproblematischer. Ein Webserver, der als Reverse-Proxy dienen kann ist ja schon da und die SSH-Tunnel machen keinen neuen Server-Dienst auf im Gegensatz zum Betreiben eines Nameservers.
Wenn man jetzt nicht stur und grundlos annimmt dass ich Dich dissen wollte, dann kommt man sehr schnell darauf, dass ich nicht wollte, dass ein (bestimmter) anderer als Du die Antwort nicht versteht.
Diesem Schluss kann ich nicht folgen.
Im Austeilen bist ja nicht schlecht. Aber beim Einstecken haperts bei Dir. Du verlierst ja offenbar schon den Verstand, wenn Du nur (und ohne wirkliche Gründe) vermutest, dass jemand Kritik an Dir üben könnte.
Ich lachte an dieser Stelle sehr laut.
Und nicht mal mit "Man kann einem gewissen Theo durchaus eine Lösung vorschlagen, aber wenn es mehrere gibt, dann sollte man eine wählen mit welcher der Theo voraussichtlich Erfolg haben wird oder wenigstens kann." warst Du noch zu stoppen, weil Du nicht mal mehr wusstest, warum Du rennst, geschweige denn woher Du kommst und was Du auf die Hörner nehmen willst...
Nein, du interpretierst das falsch, wie ich inzwischen verstanden habe, fehlt es dir an Verständnis dafür, wie einfach meine vorgeschlagene Lösung ist. Deine Einschätzung dass Theo das nicht umsetzen könnte ist vermutlich völlig falsch und deshalb konnte ich deine Aussagen nicht verstehen.
Wut, mein Freund, ist ein schlechter Ratgeber.
Danke Mr. Rotglut.
mfg
Woodfighter-
Das ist eine durchaus akzeptable, unter Beachtung und Wichtung der von Dir genannten Umstände womöglich sogar die vorzuziehende Lösung. Allerdings hast Du im von Dir verlinkten Beitrag durch die Blume auch gesagt warum diese sich im konkreten Einzelfall als unbeherrschbar erweisen könnte.
ich plädiere auf, du wolltest nur rumstänkern.
Das aber nur, weil Du es so verstehen willst.
nein, s/willst/musst/
Also wenn das derart zwanghaft ist, dann solltest Du das untersuchen lassen. Aber gut, dass Du nicht mehr mit mir kommunizierst.
Wut, mein Freund, ist ein schlechter Ratgeber. Danke Mr. Rotglut.
-
-
Hallo,
Wut, mein Freund, ist ein schlechter Ratgeber.
ich dachte immer „Wood“ in Woodfighter stünde für „Holz“, aber es ist Lautmalerei!?
Gruß
Kalk
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Hallo henry,
Ein Bezahl-Zertifikat will man nicht. Ein 90Tage Zertifikat ist auch nicht das wahre. Eine neue "beta" mit kostenlosen Zertifikaten werde ich sicher nicht nutzen.
Eine kleine Ergänzung dazu:
Die Gültigkeit von nur 90 Tagen wird mit verbesserter Sicherheit begründet, ein kompromittiertes Zertifikat mit mehreren Jahren Laufzeit hat ein größeres Schadenpotential als eines mit nur 90 (bei Let’s Encrypt plant man daher in Zukunft auf 30 Tage zu verkürzen) – durch die Automatisierung ist die Zertifikatserneuerung keine große Sache. Außerdem hat Let’s Encrypt den Beta-Status bereits verlassen.Gruß
Julius
-
-
-