Beiträge von eripek

Zitat von VVV

fragwürdiger Werbespruch der Wirtschaftskammer

Mitnichten! Das ist das „Leitlprinzip“.

Zitat von ASS

Diesel?

Kürzlich um 1,139 Benzin getankt.

Diesel hätte ich da um 1,019 bekommen, hatte aber gerade keinen Kanister mit.

Witzig jedenfalls, dass wenn Russen und Saudis streiten, während Europa sich vor jedem Niesen fürchtet, der Sprit billiger wird.

Zitat von mainziman

in AT wurde soeben im Laberfunk das Maßnahmenpaket verkündet;

Unis, FHs sind geschlossen;

Veranstaltungen

- Indoor über 100 Personen

- Outdoor über 500 Personen

sind untersagt;

Soziale Kontakte soll man vermeiden;

aber eine Shopping Mall ums Eck hat Vollbetrieb wie wenn nichts wär

und die dazugehörige Parkhausagglomeration mit in Summe mehr als 5000(!) Stellplätzen

ist ja nur f. 100 Personen???

Alles anzeigen

Ist doch kein Problem - ich mein, wir fahren ja U-Bahn auch. Drah di ned um, oh, oh, oh Das Corona geht jetzt um ...

Zitat von Longi

Wie würde so eine Route dann beispielhaft aussehen?

Na so, dass die IP-Adresse Deines VPS + "/32" "via" IP-Adresse von FB/SP geht.

Zitat von killerbees19

Habe ich eigentlich schon oft genug erwähnt, dass ich Python wirklich hasse?

Ich habe gerade damit angefangen... und bin Deiner Meinung. Und es sich so viele Leute dieser Meinung, dass Python-Entwickler anscheinend hoch im Kurs stehen...

Zitat von mfnalex

Bei Minecraft gibt‘s noch Villager und Pillager

Erinnert mich an den Wortwitz zu Corona und Coroner...

Zitat von ASS

Naja, sind eben "Unterstützungs Maschinisten". Die haben früher die Kohlen ins Feuer geschippt...

So gesehen stand auf einer meiner ersten Visitkarten „Hilfstischberater“.

Damit hätte ich sicher auch zu Roller, Poco und den Rotstühlen gehen können...

Zitat von Longi

Nein, sollen nur die Clients die direkt mit dem VPS per VPN verbunden sind den Broadcast vom VPS empfangen können.

Na dann ist es ja relativ simpel - Der VPS macht einen Layer 2-Tunnel und auf dem Tunnel-Interface läuft ein DHCP-Server, der Adressen an die Clients aus einem privaten Netz vergibt. Pass auf, dass er aber keine Defaultrouten/-Gateways verteilt damit Du keinen flappenden Tunnel baust. Auf den Clients empfehlen sich statische Routen über die Fritzbox oder den Speedport zur IP-Adresse Deines VPS. Damit nehmen die Clients an einem IP-Netz Deines VPS teil und können auch am Ethernet dort teilnehmen.

Zitat von milky

Ich kenne nun seit Jahren diese XML Datei und niemand hat sich mal hingesetzt und ein kleines Web Interface dazu gebastelt ...

Das hat sicher auch seine Gründe: Die Mehrheit der bestellbaren Produkte ist auch auf netcup.de, netcup.eu und netcup-sonderangebote.de zu finden.

Die restlichen Produkte beauskunftet Dir auch der Support, wenn Du sie brauchst, nett fragst und/oder ein Individualangebot brauchst. Ist auch weniger frustrierend, als Links mit der Überschrift: „Dieses Produkt ist nicht mehr verfügbar“, „Der Produktschlüssel ist ungültig" und dergleichen...

Zitat von milky

Ich hab jetzt kein "Beitrag bearbeiten" gefunden - deshalb an dieser Stelle, ja... ich habe da jetzt meine Kundennummer mit eingepflegt... kurze Zeit nachdem ich das hier gepostet hatte. Insoweit stimmt es, das die Adresse https://nc.mcmilk.de/netcup/ nun Ref Links promotet.

Hast Du die Links denn auch geprüft, ob sie denn auch gültig sind, und die Produkte überhaupt noch bestellbar sind, oder einfach nur mal so online gestellt? Das XML-File beinhaltet zahlreiche Einträge, die einfach nicht mehr stimmen, oder wo Produkte drinnen sind, die keine Produktbeschreibung haben, oder sonst aus einer Aktion stammen, die es nicht mehr gibt, etc, etc...

Also das 1:1 zu übernehmen, halte ich gegenüber den Kunden, die Du damit zu werben versuchst, nicht für fair. Pardon, das musst raus.

Zitat von Longi

Von Fritzboxseite her bekommen sie ja eine IP aus dem Bereich 192.168.178.xxx. Und bei nem Speedport 192.168.2.xxx.

Ich hoffe, das Forum zeigt meine ASCII-Graphik stabil an:

X1, X2, X3 ... irgendwelche externen IP-Adressen der Provider

Ausgangslage:

                                           VPS (X1)                                              |[192.168.178.0/24]---[Fritzbox] (X2)--------{Internet}-------(X3)[Speedport]---[192.168.2.0/24]

Layer 3 (tun): VPN 172.16.0.0/24 ist frei gewählt.

                                        === VPS (X1) [VPN: 172.16.0.254]===
                                    VPN/        |                           \VPN
                                  =====         |                            =====      
[192.168.178.0/24]---[Fritzbox] (X2)--------{Internet}-------(X3)[Speedport]---[192.168.2.0/24]
                [172.16.0.1]                                                    [172.16.0.2]    

Die Tunnelendpunkte können sich gegenseitig auf Layer 3 erreichen - keine Broadcasts. Clients hinter dem Endpunkt müssen eine Route erhalten, damit sie ins jeweils andere Netz kommen. Sofern 172.16.0.0 über deren Gateway erreichbar ist, genügt hier eine Defaultroute.

Layer 2 (tap):

                               ===     VPS (X1) ===
                           VPN/             |       \VPN
                           ===              |         ===
[192.168.178.0/24]---[Fritzbox] (X2)--------{Internet}-------(X3)[Speedport]---[192.168.2.0/24]


ist so wie 

                         [ Switch ]
VPS ----------------------||    |
                  Fritzbox/      \Speedport

D.h. Du hast in dieser Variante eine Broadcast-Domain geschaffen, in der aller Traffic zusammengeschaltet ist.

Dein Problem ist nun, dass Du wegen der unterschiedlichen Client-IP-Ranges auf FB und Speedport verwirrt bist, respektive auf dem Server gar kein IP-Range solcher Range vorhanden ist - zu Recht verwirrt Dich das, denn die Router machen üblicherweise Layer 3 Tunnel, und das ist etwa bei mobilen Breitbandnetzen auch die Variante, die am ehesten noch Kosten spart, weil nur selektiv Traffic darüber läuft.

Die Frage ist jetzt, ob es Dir genügt, wenn nur einzelne Clients hinter den Routern am VPN teilnehmen, oder, ob Du alle Clients mit den Broadcasts versorgen möchtest.

Im ersteren Fall nehmen die jeweiligen Clients selbst am VPN teil. Sie dürfen dann vom VPN-Server, respektive einem auf seinem Interface (empfohlen software-bridge + tap-Device als Bridgeport) eine Adresse per DHCP erhalten.

Ihr jeweiliges VPN Interface nimmt dann an der Broadcast-Domain "lokal" teil.

Im anderen Fall müsste man den Layer 2 auf den LAN-Ports der Router ausgeben, was ohne zusätzliche Hardware und VLANs ziemlich komplex werden kann...

Zitat von Longi

Einen wunderschönen guten Tag wünsche ich

Nicht dass ich viel Ahnung von dem hätte was ich vorhabe. Daher dachte ich "frag einfach mal"

Ich habe einen VPS und würde auf diesem gerne eine Anwendung laufen lassen die einen Broadcast an die mit dem Server verbundenen Clients sendet - und natürlich auch Antworten bekommen- kann.

Hab recherchiert dass Broadcast über Layer 2 des Netzwerkprotokolls läuft. Also muss ich eine VPN-Verbindung im Bridge-Mode herstellen. Allerdings bedingt dies dass der Client transparent in das Einwahlnetz eingewählt wird und eine IP-Adresse des dortigen Subnetzes erhält.

Nur hab ich beim VPS ja kein Sub-Netz. Die Anwendung soll ja nicht auf einer Maschine hinter dem VPS laufen sondern auf ihm selbst?

Hab ich da vllt. einen Denkfehler? Und ist mein Vorhaben überhaupt (so oder anders) realisierbar?

Vielen Dank schon mal...

Alles anzeigen

Deine VPN-Lösung wird mit an Sicherheit grenzender Wahrscheinlichkeit über das IP-Protokoll abwickelt.

VPN bedeutet im einfachsten Fall Verkapselung. Ein Paket wird in ein IP-Paket (IP oder auch IP mit UDP, TCP) verpackt und auf die Reise geschickt - auf der anderen Seite wird es wieder ausgepackt.

Das Paket, das Du einpackst, kann auch ein Ethernet-Frame sein - dann bist Du auf Layer 2 und es stehen Dir alle darin verfügbaren Broadcasts zur Verfügung. Das wäre dann der ein Layer-2-Tunnel an den Du anscheinend denkst. Auf Layer 2 hast Du natürlich kein Subnet, weil das erst auf Ebene 3 existiert.

Als Subnetz kannst Du einen der privaten Bereiche aus RFC1918 verwenden: 10.0.0.0/8, 172.16.0.0/12 oder 192.168.0.0/16.

Packst Du ein Layer 3-Protokoll ist es ein Layer 3-Tunnel - beispielsweise ein IP.

Stell Dir das vielleicht wie eine Zwiebel vor, die über den Boden rollt. Die Außenhaut ist IP, innen ist was auch immer. Die Packetgrößen nach innen werden aber immer kleiner (MTU/Fragmentierung) - das ist das, wo man mit der Zeit zu weinen beginnt ;-). Dazu eventuell später mehr.

Der Trend geht zur Zweit- und Drittapp. Es gibt einfach für Alles eine App. Wie gunnarh schon angemerkt hat, ist in vielen Fällen eine responsive Web-App die bessere Lösung. Was ich mit Sorge beobachte, ist, dass Apps beim Erstrelease rank, schlank und funktioniell sind, mit der Zeit aber von 5MB auf 50 MB oder mehr anwachsen. In vielen Fällen würde es genügen, um eine Proforma-App herum die Webapp zu laden.

Grundsätzlich finde ich den Ansatz beim SCP auch gut, denn somit hätte man Basisfunktionen der Steuerung mit - andererseits: möchte ich auf einem Mobilgerät überhaupt so wichtige Zugangsdaten haben? Anschauen werde ich es mir auf jeden Fall!

Bei der Menge der Postings in den letzten Tagen frage ich mich, ob bei Euch der Urlaub ausgebrochen ist?

Apropos SCP-Quirks... Doppeleingaben in der VNC-Shell ... Das Thema ist leidig und alt.

Zitat von H6G

Solange die das nicht bei sich reproduzieren können. Das SCP hat ja einige Quirks, die leider nicht angesehen werden, weil Netcup sie nicht reproduzieren kann.

Oder auch offensichtliche Quirks... in Zusammenhang mit CSS und synchronen XMLHttpRequests.

Diese Seite verwendet die nicht standardisierte Eigenschaft "zoom". Stattdessen sollte calc() in den entsprechenden Eigenschaftswerten oder "transform" zusammen mit "transform-origin: 0 0" verwendet werden.

Synchrone XMLHttpRequests am Haupt-Thread sollte nicht mehr verwendet werden, weil es nachteilige Effekte für das Erlebnis der Endbenutzer hat. Für weitere Hilfe siehe http://xhr.spec.whatwg.org/ jquery.min.js:2:80629

Zitat von friend_of_root

Du darfst die Domain nicht in seinem Namen kündigen. Das wäre Unterschriftsfälschung.

Davon war keine Rede. Domains haben in der Regel aber eine Laufzeit. Wenn die abläuft, ohne verlängert zu werden, kommen wir zum selben Ergebnis. So gesehen dürftest Du die Domain ohne Mandat des Kunden auch nicht selber verlängern.

In jenen Fällen, wo Dein Kunde es nicht schafft richtige und aktuelle Kontaktdaten anzugeben, verstößt er auch gegen die AGB von nic.at, konkret gegen Punkt 1.3. In so einem Fall ist es tunlich, dass Du nic.at einfach nur darüber informierst, dass die Kundendaten augenscheinlich nicht (mehr) korrekt sind, oder der Kunde auf Nachrichten nicht mehr reagiert. Damit treten die Folgen des Punkt 3.8 „Widerruf der Delegation“ ein. Einer der Punkte bezieht sich auf mangelhafte Angaben zum Domain-Inhaber gem. 1.3.. Siehe dann auch 3.9: „Handlungen und Erklärungen des Registrars in Bezug auf die Domain werden dem Domain-Inhaber zugerechnet.“

Und, wenn ein Kunde die Domain nicht konkludent durch Zahlung verlängert oder erklärt, dass er sie verlängern möchte, dann läuft der befristete Vertrag aus. In diesem Fall ist meiner Ansicht nach eine Kündigung gerade nicht erforderlich. Wenn Registrare Resellern also einen Kündigungsbutton zur Verfügung stellen, nicht aber eine Möglichkeit zur Eintragung der Befristung, dann wende Dich im Zweifel an den Support.

Ich kann nur aus Erfahrung berichten, dass andere Anbieter wie dd**.** und in**.** in deren Kundenportalen diese Möglichkeit bieten, Wieso netcup hier entgegen seiner sonstigen Firmenphilosophie einen Support-lastigen Weg gewählt hat, kann ich mir nicht erklären. Detto wäre das bei internationalen Inklusivdomains suboptimal gelöst.

Zitat von friend_of_root

Wenn die .at Domain auf einen Kunden läuft, dann kann man diese Domain nicht einfach kündigen.
Dafür braucht man ein unterschriebenes Dokument vom Kunden. Es wäre absolut unkorrekt die Domain zu kündigen in seinem Namen.

Bei einem Kunden der selbst in verschuldetem Zahlungsverzug ist, vermag ich die Inkorrektheit dieses Vorgehens nicht erkennen. Ein Rücktritt vom Vertrag wie auch die Nichtverlängerung ist in diesem Fall sicherlich zulässig. Eventuell helfen die https://www.nic.at/de/so-funktioniert-at/faqs/ weiter? Wartestatus scheint in diesem Fall nicht zuzutreffen.

Zitat von friend_of_root

Wenn man von eine .at Domain von einem Kunden bei netcup kündigt, bzw. nicht verlängert.. Geht sie zurück zur zentralen Registrierungsstelle nic.at so wie bei anderen Hostern, oder gibt es eine andere Lösung?
Hintergrund sind z.B. Kunden die den Vertrag kündigen aber die Domain dann doch behalten wollen, Kunden denen man kündigt (zB nachdem sie 1 Jahr nicht gezahlt haben), oder einfach Übergabe an einen Kunden der mit Authcode und so weiter dann am Ende des Vertrags mit uns zu spät dran ist.

Du meinst soetwas wie Domainparking, sodass Du die ausgelaufene Domain erst einmal selber als Werbefläche anbieten und später verscherbeln kannst?

Lange Zeit war es bei .at-Domains üblich, dass man für den Differenzzeitraum Ende der Registrierung - Ende des Registrar-Vertrags bei vielen Anbietern nichts gezahlt hat, weil ja die Jahresgebühr für die Verlängerung an nic.at ohnehin abgeführt war.

Leider hat sich seit gut 15 Jahren die Unsitte eingebürgert, dass man als Anbieter da erst einmal abcasht und das mit Administrationskosten und Nameservern begründet - was unterm Strich gerechnet aber meist unbegründet erscheint.

Anderes Thema: eigentlich hätte ich mir für den heutigen 29. Februar 2020 ein vierjähriges Topangebot von netcup erwartet... Immerhin kommt der nächte 29.02. erst 2024 wieder.

Ja, der Begriff „Subdomain“ wird leider auch überstrapaziert.

Wenn es um einen CNAME geht, muss man den bei netcup über das CCP im Bereich Domains anlegen.

Den Server-Alias (oder Server-Name) anzulegen, der in Plesk leider auch als „Subdomain“ bezeichnet wird, geht über den Button „Auto-Login WEB“ im CCP unter dem entsprechenden Produkt (Lupe anklicken) - da kommt man dann in Plesk und kann dort unter

pasted-from-clipboard.png

...

Dafür ist dann aber ein Hosting erforderlich.

Was Du wahrscheinlich auch meinen könntest, ist eine „Domain-Weiterleitung“, wo der DNS-Anbieter Dir einen Proxy-Server oder eine Frame-Seite unter der „Subdomain“ anbietet, sodass unter der dann angelegten „Subdomain“ der Inhalt einer anderen Website dargestellt wird.

So etwas habe ich bei netcup noch nicht gesehen. Nur die umgekehrte Funktion, den Aufruf einer Domain über

https://sslconnection.de/domainna.me
gibt es - unter „SSL-Proxy“.

Zitat von DerRené

Dennoch muss man gewisse Voraussetzungen erfüllen. Ob diese, gerade am genannten Beispiel des Mail-Tests, gegeben sind...?

1. Domains darüber zu registrieren (Inklusivdomains) ist nicht vonnöten.

2. Ein Webform ist je nach Art statisch oder nicht.

3. Filehosting wird hier auch nicht getestet, sondern ein Mailproblem.

4. Feedback geben wir ja bereits im Forum - nur dann eben an anderer Stelle im Forum.

5. Mindestverfügbarkeit braucht es für den Test nicht.

6. Dass der Vertrag mit Monatsfrist kündbar ist, ist ja ein Vorteil, wenn man nur mal eben was testen möchte, woran netcup -siehe 4.- Interesse haben kann.

7. Um Support geht es ja nicht...

Zum Testen werden 7 Tage ja wohl reichen...

Alternative: Support anschreiben und um einen regulären Testaccount ersuchen.