Beiträge von teneco

  • Lässt sich ein RS500SASG7 zu einem RS1000SASG7 aufbohren?

    Hallo,


    ich würde gerne den Aufwand für die Migration eines Servers minimieren. Meine Frage: könnte ich meinen vorhandenen RS500SASG7 zu einem zu einem RS1000SASG7 aus dem Herbstangebot aufbohren? Ziel ist es nicht wieder alle DNS-, rDNS Einträge anpassen zu müssen.

    Kaufmännisch hätte ich dann natürlich einen Server mehr und würde den 500er dann zu seinem regulären Vertragsende hin kündigen.


    Gruß, Stefan

  • zu kleine Partition bei RS 1000 SAS G7SE 15 years

    Ok,ja, danke.


    Merkwürdig bleibt der Unterschied zu den anderen,

    Da sieht es so aus:


    xxxxadm@mail:~$ df -h

    Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf

    udev 1,5G 0 1,5G 0% /dev

    tmpfs 301M 16M 286M 6% /run

    /dev/sda1 234G 20G 202G 9% /

    tmpfs 1,5G 0 1,5G 0% /dev/shm

    tmpfs 5,0M 0 5,0M 0% /run/lock

    tmpfs 1,5G 0 1,5G 0% /sys/fs/cgroup

    tmpfs 301M 0 301M 0% /run/user/1000

  • zu kleine Partition bei RS 1000 SAS G7SE 15 years

    Hallo,

    ich habe auf drei VServern Ubuntu 16.04 auf die gleiche Weise installiert; immer sollte der gesamte Plattenplatz einer Partition zugewiesen werden. Zwei vServer sind "RS 500 SAS G7 SE 12M" und einer ist ein "RS 1000 SAS G7SE 15 years".

    Bei letzterem ist die Partiton sda viel zu klein:

    df -h

    Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf

    udev 2,9G 0 2,9G 0% /dev

    tmpfs 597M 8,2M 589M 2% /run

    /dev/mapper/mail2--vg-root 301G 6,8G 279G 3% /

    tmpfs 3,0G 0 3,0G 0% /dev/shm

    tmpfs 5,0M 0 5,0M 0% /run/lock

    tmpfs 3,0G 0 3,0G 0% /sys/fs/cgroup

    /dev/sda1 472M 346M 102M 78% /boot

    tmpfs 597M 0 597M 0% /run/user/1000


    root@mail2:~# dmesg | grep sda1

    [ 1.304443] sda: sda1 sda2 < sda5 >

    [ 11.421600] EXT4-fs (sda1): mounting ext2 file system using the ext4 subsystem

    [ 11.423386] EXT4-fs (sda1): mounted filesystem without journal. Opts: (null)


    Wie kann ich die Partion sda1 aufbohren?

  • Linux Pad?

    Kennt jemand ein gutes Pad mit Linux als Alternative zum sonstigen Einerlei?


    Grüße aus Berlin, Stefan


    PS. es kann natürlich auch ein erfolgreich nachgerüstetes sein. Was sind Eure Erfahrungen?

  • UFW Firewall übersteht Neustart nicht unbeschadet

    ich habe mehr Indizien: es verschwinden aus den IP-tables nicht alle sondern scheinbar nur die zuletzt per UFW hinzugefügten Regeln. Auf dem Rechner, auf dem die Regeln den Neustart nicht unbeschadet überstehen ist das Paket "iptables-persistent" installiert - auf den anderen nicht. jetzt habe ich das Paket entfernt, den Rechner neu gebootet und siehe da - alles noch da. Scheinbar haben vorher sowohl UFW als auch dieses Paket iptables-persistent versucht die ip-tables nach einem Neustart zu restaurieren - heraus kam etwas nicht konsistentes.

  • UFW Firewall übersteht Neustart nicht unbeschadet

    Hallo,


    auf einem meiner root Server (Ubuntu 16.04) übersteht die per UFW eingerichtete Firewall einen Neustart nicht unbeschadet. Einige Regeln sind weg, andere irgendwie doppelt. Durch ein "ufw disable" "ufw enable" werden die IP-Tables weitestgehend restauriert.

    Schaut man sich nach einem Neustart die ufw Regeln per "ufw status verbose" an sehen sie noch so aus wie vor dem Neustart - ein ip6tables -n -v --list sieht aber anderes aus als vor dem Neustart und auch anders nach dieser Kombination von "ufw disable" "ufw enable".



  • automatisches Einbinden des storagespace hakelt

    OK, guter Vorschlag. AutoFs ist ja in Ubuntu 16.04 in Systemd enthalten. Habe den Cron Job wieder entfernt. und den Eintrag in FSTAB geändert zu:

    Code
    46.38.248.210:/voln12345a1 /mnt/storagespace nfs noauto,x-systemd.automount,x-systemd.device-timeout=10,timeo=14,x-systemd.idle-timeout=1min 0 2

    Scheint so zu laufen wie erwartet.

  • hop-limit IPV6

    Nach dem Reboot hat es mir auf einem Rechner wieder einen Teil der IP Table zerrissen: hier ein Teil aus ip6tables -n -v --list vorher:

    Code
    Chain ufw6-user-input (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     tcp      *      *       ::/0                 ::/0                 tcp dpt:1222 /* 'dapp_OpenSSH' */
    0     0 ACCEPT     tcp      *      *       ::/0                 ::/0                 multiport dports 80,443 /* 'dapp_Apache%20Full' */
   11   880 ACCEPT     tcp      *      *       ::/0                 ::/0                 tcp dpt:25 /* 'dapp_Postfix' */
    0     0 ACCEPT     tcp      *      *       ::/0                 ::/0                 tcp dpt:465 /* 'dapp_Postfix%20SMTPS' */
    0     0 ACCEPT     tcp      *      *       ::/0                 ::/0                 tcp dpt:587 /* 'dapp_Postfix%20Submission' */
    0     0 ACCEPT     tcp      *      *       ::/0                 ::/0                 tcp dpt:4190
    4   320 ACCEPT     tcp      *      *       ::/0                 ::/0                 multiport dports 143,1234 /* 'dapp_Dovecot%20Full' */

    nach dem Boot:

    nach einem ...

    Code
    sudo ufw disable
sudo ufw enable

    ..werden die IPTABLES teilweise wiederhergestellt:

    bleiben die udp-Einträge, die vorher nicht da waren.

  • automatisches Einbinden des storagespace hakelt

    Also die Netzwerkkonfiguratinen sind gleich:

    Die Mount-Optionen _netdev ändert am Verhalten nichts.

  • automatisches Einbinden des storagespace hakelt

    Zitat

    Wie ist es, wenn du den Server runterfährst, auf dem es klappt (und ausgeschaltet lässt) und dann einen der anderen rebootest

    Das habe ich auch ausprobiert - da ändert sich nix. Auch kann ich auf dem ausgetimten Rechner das LW von Hand mounten und dann den anderen booten - der Boot läuft da wieder problemlos durch.

  • automatisches Einbinden des storagespace hakelt

    ich habe drei Root-Server mit Ubuntu 16.04. Mit einem ist ein storagespace verknüpft. Für die anderen sind deren IP-Adressen im storage space freigegeben. Bei allen kann ich das Laufwerk mounten und darauf zugreifen. Nur das automatische Einbinden via fstab funktioniert nur bei dem Rechner bei dem der storagespace verknüpft ist. Der Eintrag in fstab sieht bei allen drei gleich aus:

    46.38.248.210:/voln12345a1 /mnt/storagespace nfs defaults 0 2

    Nur der eine Rechner läuft beim Booten glatt durch; die beiden anderen bleiben beim Einbinden des storagespaces hängen "a start job is running for /mnt/storagespace (1 min 37). Nach Ablauf der 1:37 geht es weiter.


    Im Syslog steht im Fehlerfall:

    mnt-storagespace.mount: Directory /mnt/storagespace to mount over is not empty, mounting anyway.

    Mounting /mnt/storagespace...

    mnt-storagespace.mount: Mounting timed out. Stopping.

  • hop-limit IPV6

    Nein, ich habe nur eine IPv6 Adresse eingerichtet.

    Ich habe jetzt die FW deaktiviert, alle Regeln raus geworfen und neu aufgesetzt; konsequent mit dem ufw app - also wo für einen Dienst wie Postfix oder Dovecot mehrere Ports eingerichtet sind - vorher gab es für jeden Port eine Regel. Bislang scheint alles zu laufen.

  • hop-limit IPV6

    also das Problem ist, dass in einem der beiden Rechner die FW Regel für den Dovecot Replication Port nach einem Neustart verschwindet.

    Aufgesetzt wurde die Regel auf beiden Rechnern (Ubuntu 16.04) mit dem Befehl
    ufw allow from 2a03:4000:17:yyyy::1 to any port 1234 proto tcp

    Bei einem ip6tables -n -v --list ist die Regel auch wieder zu finden. Allerdings nicht mehr nach einem Reboot. Auf dem anderen Rechner überlebt die Regel einen Reboot. Lässt man sich nach dem Reboot den Status der UFW anzeigen scheint die Regel auch noch da zu sein:


    In den IP-Tables ist aber der Eintrag für den Port 1234 verschwunden.

  • hop-limit IPV6

    Ist nicht reproduzierbar: jetzt läuft es ohne Änderungen der Regeln auch wieder mit IPV6. Es lief auch schon 2 Tage vorher. Ich melde mich hier wieder sobald es neuerlich auftreten sollte.

  • hop-limit IPV6

    manchmal erreicht der eine Ubuntu Root-Server den anderen nicht mehr über IPV6. Bei dem anderen steht dann im Syslog:


    Jul 11 15:40:25 mail kernel: [ 2238.307030] [UFW BLOCK] IN=ens3 OUT= MAC=56:37:f7:ed:7a:45:2c:6b:f5:a0:77:c0:86:dd SRC=2a03:4000:0017:yyyy:0000:0000:0000:0001 DST=2a03:4000:0006:xxxx:0000:0000:0000:0001 LEN=80 TC=0 HOPLIMIT=63 FLOWLBL=180741 PROTO=TCP SPT=52948 DPT=1234 WINDOW=28800 RES=0x00 SYN URGP=0


    Auch bei abgeschalteter FW kommen die Pakete dann nicht durch. Ein MTR -6 funktioniert in beide Richtungen.

    Nehme ich für die Dovecot Replication wieder die IPV4 Adressen ist alles gut.

  • Ubuntu Server für Minuten nicht erreichbar

    Hallo,

    es handelt sich nicht um einen vServer (auch wenn ich ihn so nennen würde) sondern um, wie NETCUP sie nennt, Root-Server (RS500SAS G7). Der Support hat mich ermuntert hier im Forum zu posten; nachdem ich ins Rettungssystem booten konnte und ein MTR problemlos lief war die Antwort vom Support:

    Code
    Ein Netzwerkfehler kann somit ausgeschlossen werden. Am Host-System konnten wir keinerlei Auffälligkeiten feststellen.

Sie besitzen bei uns einen Server. Wir stellen Ihnen die Laufzeitumgebung bereit. Zu individueller Software und zur Einrichtung können wir keinen Support geben. Nach Einrichtung haben wir keinen Zugriff mehr auf Ihr System. Die Einrichtung und Konfiguration Ihrer Dienste und Pflege obliegt Ihrer Verantwortung.

Hilfreiche Tipps finden Sie online und in Fachliteratur. Auch ist für Ihre Fragen unser Kundenforum ein guter Anlaufpunkt, in welchem sich unsere Kunden gegenseitig unterstützen.

    Es ist ein schwer zu findender Fehler. Das ist dummerweise mein Produktivsystem; ich werde jetzt einen anderen Rechner als produktiven neu aufsetzen und dann kann ich auch weitergehende Untersuchung in dem Rettungssystem machen.