Posts by Exception

    Die Meldung passt doch nur, wenn der Server eine geringere Bandbreite hätte, als das vLAN.

    Sollte doch egal sein, oder? Diese Angabe würde ja nur die externe NIC betreffen. Wenn ich aber ein VLAN mit 2,5 Gbit/s buche und dem Server eine zusätzliche virtuelle NIC aus dem VLAN gebe, dann sollte diese NIC auch 2,5 Gbit/s haben - unabhängig welche Bandbreite die primäre NIC hat.


    Ich habe bislang immer nur das Cloud VLAN Free Produkt genutzt. Wenn man ein höheres Paket bucht, muss man das für jeden einzelnen Server machen oder nur einmalig? Weil nur dann würde diese Meldung Sinn machen.


    Edit: Bei meinen Server steht die Meldung auch. Ich glaube, dass ist einfach ein Fehler.

    Dieselbe Einschränkung bzgl. Unmöglichkeit der Firmware-Auffrischung dürften zwecks Manipulationsabsicherung fast alle Hardwaretoken haben (gilt auch für Yubikeys).

    Ist das wirklich ein großer Vorteil? Insbesondere bei Yubikey gab es vor kurzem eine Sicherheitslücke in einer Infineon-Krypto-Bibliothek des Yubikeys. Dadurch das keine Updates möglich sind, bleibt einem nur die Option eines Neukaufs. Deshalb habe ich auch den Nitrokey im Blick, denn dieser lässt Firmware Updates zu.

    Your server currently has an APIPA address, i.e. your server was probably unable to reach the DHCP server. You could open the console and enter the commands: ipconfig /release and ipconfig /renew. Or you could statically assign the IP address to the server.


    Sorry but as a server administrator you should know this. Please note that you bear sole and full responsibility for the server and that you may also be held liable if damage occurs due to negligence.

    Open the CMD and enter the following command: ipconfig /all


    Then check whether the IP address, subnet mask and gateway details are correct. Then check whether a correct DNS server has been entered. The DNS server 8.8.8.8 is from Google. Is ok for testing. However, I would always use the provider DNS, i.e. the Netcup resolvers.

    my Internet access went from 'Not connected' to 'Verifying... No Internet' (see first image) over and over again.

    But the interface is visible in Windows? Then the driver seems to be working. What does the network configuration of the interface look like? By the way: which Windows Server version are we actually talking about?


    Edit: Ah. I see you've added the screenshots to the thread. As I said before, something seems to be wrong with your network configuration of the interface. You are probably missing the DNS server.

    Ich sage nur Firewalls.

    Genau das mache ich auch. Auch hier bei Netcup. Ich habe zwei Server. Auf dem einen läuft ein Mikrotik CHR. Und dann habe ich einen Backend Server. Beim Backend Server ist die NIC mit der öffentlichen IP abgeschaltet. Bei der VLAN NIC gibt es eine statische RFC1918 Adresse und das Default Gateway zeigt auf die interne IP des Mikrotiks.


    Dadurch ist mein Backend Server nicht mehr für die Ausenwelt erreichbar. Somit sind auch keine Angriffe von extern möglich.


    Damit mein Server wieder öffentlich erreichbar ist, müssten es drei Bugs geben:


    - Ein Bug müsste die öffentliche NIC wieder aktivieren

    - Ein Bug müsste den DHCP Client aktivieren

    - Der letzte Bug müsste dann die administrative Distanz im Netzwerk Stack manipulieren damit man die statische Route umgeht. Denn statisches Routing hat eine höhere Wichtung als Dynamisches bzw. DHCP.


    Oder übersehe ich was?


    Edit: Kleiner Nachtrag noch. Du musst mir nicht erklären, was eine Firewall ist und warum diese eigentlich Standard in jedem Netzwerk sein sollte. Mir ging es wirklich nur um den einen Kommentar, warum man eine softwareseitig abgeschaltete NIC nicht vertrauen kann. Das halte ich nach wie vor für falsch. Wenn ihr das anders seht, dann freue ich mich über euer Feedback. Denn aktuell betreibe ich das so wie beschrieben und ich hatte nie Probleme damit (und ich sehe damit auch weiterhin keine Probleme). Deshalb wäre mir Feedback umso wichtiger, falls das jemand anders sieht. Aber bitte mit Begründung. :)

    Wie gesagt, alles was du deaktivierst, kann auch wieder aktiviert / umgeschrieben werden.

    Natürlich kann das wieder aktiviert werden. Aber sicherlich nicht durch ein Bug im System bzw. es müssten dann schon mehrere kritische Bugs sein die gleichzeitig auftreten. In solch einem Fall würde ich grundsätzlich das verwendete Betriebsystem in Frage stellen. Und sollte Schadsoftware auf dem Server sein, dann hast du grundsätzlich verloren. Dann ist es ohnehin egal, ob der Server direkt oder über eine Firewall seine Verbindung ins Internet nimmt.


    Ansonsten hast du natürlich Recht. Viel schöner und "richtiger" wäre es, wenn man die Server auch nur mit dem VLAN NIC betreiben könnte. Dann kann der Kunde (und auch Netcup) die öffentliche IPv4 Adresse sparen. Mir ging es aber nur um den Sicherheitsaspekt, dass man die Server trotz der abgeschalteten NIC mit der öffentlichen IP sicher und ohne jegliche Bedenken betreiben kann.

    Da würde ich mich jetzt nicht darauf verlassen.

    Warum nicht? Ich mache das exakt so. Das Interface mit der öffentlchen IP ist bei mir abgeschaltet, während die andere NIC mit dem VLAN aktiv ist. Gab noch nie Probleme damit.


    Und wenn man wirklich Angst davor hat, dass ein Bug das Interface wieder aktiv schaltet, dann könnte man immer noch den DHCP Client vollständig deaktivieren oder einfach das Interface statisch mit einer RFC1918 Adresse austatten. Abgesehen davon ändert sich ja auch am Routing nichts. Selbst wenn die NIC wieder aktiv wird und bei der NIC die öffentliche IP Adresse eingerichtet ist, dann wird ja trotzdem alles über die VLAN NIC geroutet (falls das Default Gateway korrekt gesetzt ist). Und wenn man ganz paranoid ist, dann kann man notfalls das Interface mit iptables zusätzlich blacklisten.


    Da müssten schon ganz schön viele Bugs auf einmal auftreten, damit da was blödes passiert. Natürlich wäre es am schönsten, wenn man die öffentliche NIC abschalten bwz. löschen kann. Einen Vorteil sehe ich allerdings nur darin, dass man sich die öffentliche IP sparen könnte.

    DKIM gehört ansonsten ins DNS und sollte bei Webhostingprodukten korrekt hinterlegt sein (TXT Record).

    Nur der öffentliche Key. Ansonsten muss natürlich auf dem Server der private Key hinterlegt sein und darauf muss der Server bzw. die Nextcloud oder der Mailserver (abhängig von den Mailsettings) zugreifen können. Ich würde daher prüfen, ob der private Key richtig auf den Server hinterlegt ist (korrekter Pfad) und ob die Berechtigungen stimmen. Ansonsten sieht mir das Log eher nach dem Access Log des Apaches aus. Für eine genauere Analyse würde ich mir das Application Log raussuchen.


    Wie bereits schon mein Vorposter erwähnt hat, fehlen hier leider viel zu viele Informationen. Die "Gemini" kann bei dieser Informationslage auch nur raten und ich vermute sehr stark, dass diese "Ratschlag" nicht wirklich zielführend ist.

    Du bist Dir sicher, dass Du das mindestens alle drei monate manuell machen willst?

    Der DNS Eintrag ist notwendig, um sich gegenüber Lets Encrypt als Domain Inhaber zu authentifizieren. Hast du ja aber wahrscheinlich selber erkannt, da du deinen Text durchgestrichen hast.

    Wo mache ich das?

    Falls die Domain bei Netcup liegt, dann im SCP -> Domains -> dann wählst du deine Domain aus und klickst links auf die Lupe -> Reirter DNS auswählen

    Allerdings muss ich zugeben, dass ich mit passwortgeschützten Keys gerade bei automatisierten Aufgaben (Ansible, cron, ...) so meine Probleme habe.

    Ich würde dir raten, nicht den Key selbst zu verschlüsseln sondern lieber den Private Key in einem Passwort Manager zu hinterlegen. Viele Passwort Manager z.B. 1password haben einen SSH-Agent mit an Board. So hat man jederzeit den Private Key an einem sicheren Ort, gleichzeitig kann man sich ganz bequem zu den Servern verbinden. Auch bieten viele Passwort Manager CLI Tools an, um eben Automatisierungen zu ermöglichen.

    Hallo,


    erstmals sei vorab gesagt: Design ist halt nun mal Geschmacksache. Das ist einer der wenigen Dinge, wo man es allen Recht machen kann.


    Deine Kritik kann ich ehrlich gesagt nicht nachvollziehen. Bei dem Screen muss ich nirgendswo runterscrollen, um den Button zu sehen oder um diesen zu klicken. Ich bin über ein normales Notebook mit 14 Zoll Display auf der Website unterwegs. Auch über mein Smartphone wird mir der Button direkt angezeigt und erst unter dem Button werden mir weitere Produktvorschläge gemacht. Ich finde es nicht schlimm, wenn man Produktvorschläge erhält - manchmal kann da auch wirklich was sinnvolles darunter sein. Solange man nicht dazu zum Kauf anderer Produkte genötigt wird. Das ist hier aber definitiv bei weitem nicht der Fall. Das einzigste was man aber wirklich Verbessern könnte, dass man auf der Desktop Version den Bestellbutton über die Vorschläge platziert - so wie bei der mobilen Version.


    Ansonsten hat sich am Bestellsystem wenig geändert. Außer dass bei der Produktseite neuerdings Addons angezeigt werden, was aus meiner Sicht für mehr Transparenz sorgt, da diese bislang auf der Produktseite nicht erwähnt worden sind und nur auf einer separaten Seite einsehbar waren. Und das die Übergänge nun fließender sind. Diesen "Effekt" kann man nun schön finden oder nicht. Stören tut er mir jedenfalls nicht.


    Den Vergleich mit der Fast Food Kette verstehe ich auch nicht, da diese ein ganz anderes Konzept verfolgen. Die Bestellsysteme werden ja schließlich mit Touch betrieben. Und die Fast Food Kette hat halt auch viel mehr Produkte, die man unterschiedlch kombinieren kann als es bei Netcup der Fall ist. Da finde ich es als Konsument doch ganz toll, wenn man durch das Bestellsystem geführt wird.


    P.S. Hätte es nicht ein passender Titel für deine Kritik sein dürfen? Dann dürften auch eher die Netcup Mitarbeiter auf diesen Thread aufmerksam werden. ;)


    MfG

    Hallo,


    so wie ich dich verstehe, dann brauchen die User nur Zugang zum Server? Oder sollen die User den Server auch verwalten können?


    Was das SCP angeht, wüsste ich nicht, dass man weitere Zugänge und Berechtigungen anlegen kann. Zumindest als Privatkunde. Man könnte höchstens noch etwas Tricksen in dem man einen API Zugang anlegt. Falls weitere Benutzer auf das SCP Zugreifen sollen, da würde ich dir empfehlen, dass du diesbezüglich den Support kontaktierst.


    Quote

    1) Partition Layout: Wir moechten eine Partition zu testzwecken nutzen und beide Zugriff darauf haben. Soll ich one big partition auswaehlen?

    Das musst du als Systemadministrator wissen. Das können wir dir nicht sagen. Für Anfänger ist eine große Partition natürlich die einfachste Option. Reicht auch für die allermeisten Anwendungen.

    2) Define user & SSH key: Wir wollen uns beide ueber unsere jeweiligen ssh keys einloggen. Heist das, ich definiere keinen User, sondern lasse die andere Person ein SSH key aufsetzen?

    Ich verstehe deine Frage nicht so ganz aber im Prinzip ist es einfach. Jeder User erhält in Linux seinen eigenen User. Entweder du erstellst für die User jeweils ein Key Pair oder der User lässt dir seinen Public Key zukommen und du hinterlegst diesen dann in der Authorized Key File.

    3) Wenn die andere Person sich per SSH einloggt, kann ich dann das Image aufsetzen bevor die Person einen SSH key hat? Macht es dann mehr Sinn, zuerst auf die zweite Person zu warten, bis sie sich einen SSH Key zulegt?

    Nicht böse gemeint aber wie gut sind deine Linux Kenntnisse? Denn wenn ich mir deine Fragen anschaue, dann habe ich leider das Gefühl, dass du nicht wirklich Ahnung hast, was du gerade machst. Dann solltest du nochmals hinterfragen, ob du wirklich bereit bist, eine richtige produktive VM zu administrieren oder ob du lieber doch noch in einer Lab Umgebung Üben / Lernen möchtest.


    Um deine Frage zu beantworten. Der Image Install Assistent im SCP (Screenshot) führt nur die Initiale Installation des Betriebsystems durch. Danach kannst du natürlich weitere Benutzer anlegen und das Betriebsystem so konfigurieren wie du das gerne haben möchtest.

    Ist natürlich klar, dass man mit so einem VLAN nur Server am selben Standort verbinden kann.

    Naja, so selbstverständlich ist das nicht. Frag mal die großen Cloud Anbieter zu diesem Thema. ;)

    pro Standort? die Frage die sich mir jetzt stellt kann ich dann den AT Server und den DE Server per VLan verbinden? sprich vom AT Server auf die Netzwerkfreigabe auf dem DE Server zugreifen?!?

    Nein, eben nicht. Das VLAN gilt nur für ein Standort. Wenn du die VLANs in DE und in AT miteinander verbinden möchtest, dann brauchst du bei beiden Standorten jeweils ein Gateway, wo du dann eine Site to Site VPN Verbindung einrichtest.