Hallo Ihr Lieben!
Ich danke euch herzlich für eure Antworten.
Durch eure Beiträge wurde klar, dass meine Konfiguration in Ordnung ist und es an der Firewall liegen musste.
Ich habe dann in dem Forum von KeyHelp nach den Firewalleinstellungen gefragt. Dort brachte mich jemand darauf, was ich die ganze Zeit übersehen hatte...
Die IP-Bereiche die ich für das VLAN nutzen wollte waren standardmäßig komplett blockiert.
Nun können sich die beiden Server direkt anpingen.
Somit bin ich ein ganzes Stück weiter gekommen. Ich hatte schon an meinem Verstand gezweifelt.
Lg Jörn
Beiträge von schimmelmann
-
-
Zitat
Zur Interface-Verwirrung - die klassische Interface-Nomenklatur eth0, eth1 usw. lässt sich für einzelne Interfaces wiederherstellen. Das ist etwa nachfolgend beschrieben: https://www.freedesktop.org/wi…bleNetworkInterfaceNames/
Ich vermute, dass so etwas zuvor einmal angewendet worden ist.
Von mir nicht. Ich habe das VLan bei Netcup geordert und die Virtuellen Schnittstellen im SCP angelegt. Durch ip li
Bin ich dann auf die Bezeichnung gestoßen.
Die anderen Infos muss ich noch durchgehen. Heute wird das aber nichts mehr. Und natürlich werde ich hier, soweit es etwas neues gibt auch berichten.
Fürs erste erst einmal herzlichen Dank! Bisher waren die Informationen sehr hilfreich. Lg -
mit arping -i ens6 192.168.xxx.2 klappt es. Dann gehe ich noch mal an die Firewall
-
Ohne mich genauer mit der vlan-Option ausseinander gesetzt zu haben: Besteht hier Layer-2 Konnektivität? Falls ja, könnte man das Setup ersteinmal folgend prüfen:
- sudo apt install arping
- sudo arping 192.168.xxx.2
(falls das nicht tut, kannst du mit -i ens6 noch das Interface angeben)
- Falls es weiterhin nicht tut, kannst du zunächst noch prüfen, ob der Server überhaupt die MAC-Adresse des anderen Systems gelernt hat:
arp | grep 192.168.xxx.2
Edit: Alternativ mal die Firewall für eine Minute abschalten und schauen, ob der Ping dann ankommt ;o)
Danke für den Hinweis. Das werde ich gleich mal testen
-
Das sieht gut aus. Dann wird es auf jeden Fall an der Firewall liegen.
Meine Interface-Config schaut auch so aus, und funktioniert problemlos.
Danke, dass ist schon mal ein wichtiger Anhaltspunkt. Dann werde ich mich an die Firewall machen.
Lg -
Ausgabe von ip address show ens6
Code3: ens6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 56:3f:af:db:f7:c5 brd ff:ff:ff:ff:ff:ff inet 192.168.xxx.1/24 brd 192.168.xxx.255 scope global ens6 valid_lft forever preferred_lft forever inet6 fe80::543f:afff:fedb:f7c5/64 scope link valid_lft forever preferred_lft forever
Code3: ens6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 7a:97:ac:af:18:bc brd ff:ff:ff:ff:ff:ff inet 192.168.xxx.2/24 brd 192.168.xxx.255 scope global ens6 valid_lft forever preferred_lft forever inet6 fe80::7897:acff:feaf:18bc/64 scope link valid_lft forever preferred_lft forever
-
Das mit der virtuellen Festplatte kommt von Netcup.
Die Firewall ist das Problem weil die über die Webhostingfläche keyhelp geregelt wird. Die haben eine eigene Verzeichnisstruktur. Da bin ich gerade dran.
Wichtig war mir, ob die Konfiguration schon mal ok ist, denn dann kann es ja nur an der Firewall liegen.
Das schränkt schon mal den Fehler ein. -
Irgendwas passt da auch bei den Interface Namen noch nicht. Auf der einen Seite nutzt du eth0, dann aber bei dem VLAN Interface ens6. Schau lieber erstmal auf dem System nach wie die wirklich heißen (wie auch whoami0501 angedeutet hat).
Die Ausgabe von
ip liergab:
Code1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1 link/loopback etc. 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether etc. 3: ens6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether etc.
Aus diesem Grund gehe ich davon aus, dass ens6 die richtige Schnittstelle ist...
Bin ich da im Irrtum? -
Wenn die Server uneingeschränkt per VLAN kommunizieren sollen, empfiehlt sich theoretisch folgendes auf beiden Servern:
Was mir noch spanisch vorkommt, ist dein "address 192.168.xxx.y/24" - das /24 braucht man eigentlich nicht. Das beschreibt ja das genutzt Subnet, aber dafür gibst du darunter ja die netmask an.
Was sagt den ein ip address show?
Danke für deine Antwort!
Die /24 hatte ich aus einem Beitrag übernommen. Die werde ich mal entfernen.
Und die Firewallregeln teste ich mal.
Dann melde ich mich wieder.
Bei ip adress show wurde die Schnittstelle ens6 angezeigt und keine Fehler gemeldet.
Wenn ich nicht weiter komme, kann ich ja die Ausgabe hier posten.
Lg -
Hallo Ihr Lieben!
Da es den Rahmen meiner ursprünglichen Frage zur MUNIN-Überwachung, die nun funktioniert sprengen würde, fange ich hier mal ein neues Thema an:
Ich habe mittlerweile viele Beiträge zum Thema VLAN durchgelesen.
Nun haben sich diverse Fragen ergeben, die ich hier mal stellen möchte:
Ausgangssituation:
Ich habe zwei VSERVER der Generation 8 gebucht. Diese möchte ich per VLAN verbinden.
Dazu habe ich testweise das kostenlose VLAN hier bei Netcup gebucht.Auf beiden Servern habe ich im SCP die virtuelle Netzkarte aktiviert.
Auf beiden Servern habe ich in der interfaces.conf folgendes eingetragen:
Server A:Code
Alles anzeigenauto lo iface lo inet loopback auto eth0 iface eth0 inet static address 37.120.xx.xx/22 dns-nameservers 46.38.xxx.xxx 46.38.252.230 2a03:4000:xxxx::fce6 gateway 37.120.xxx.x post-up ifup eth0:1 auto eth0:1 iface eth0:1 inet6 static address 2a03:4000:f:57b:543f:afff:xxxx:xxxx/64 gateway XXXX::1 # vLAN auto ens6 iface ens6 inet static address 192.168.xxx.1/24 netmask 255.255.255.0
Server B:
Code
Alles anzeigenauto lo iface lo inet loopback auto eth0 iface eth0 inet static address 46.232.251.xxx/xx dns-nameservers 46.38.xxx.xxx 46.38.xxx.xxx 2a03:4000:xxxx::fce6 gateway 46.232.xxx.x post-up ifup eth0:1 auto eth0:1 iface eth0:1 inet6 static address 2a03:4000:2b:488:7897:acff:xxxx:xxxx/64 gateway xxxx::1 # vLAN auto ens6 iface ens6 inet static address 192.168.xxx.2/24 netmask 255.255.255.0
Soweit dass was ich bisher gemacht habe.
Es gibt noch eine Firewall auf beiden Servern.
Wie müsste da die Regel lauten, damit beide Server kommunizieren können?
Über die öffentlichen IP's können sich beide Rechner anpingen.
Über die VLAN IP's nicht.Gibt es noch weiteres zu beachten?
Da meine Englischkenntnisse sehr eingeschränkt sind, würde ich mich freuen, wenn es mir jemand verständlich am oben genannten Beispiel erklären könnte.
Mir hilft i.R. ein praktisches Beispiel besser um das Grundsätzliche zu verstehen. -
Hay,
die VLAN-Nics "findest" Du im SCP. Du hast jetzt ZWEI Netzwerkkarten und ZWEI Netzkwerkkabel im Rechner stecken. Das eine Netzwerkkabel geht (vereinfacht) zum Switch für das böse Internet, das andere Netzwerkkabel geht zu einem anderen Switch, der Deine Rechner untereinander vernetzt.
Das zweite Netzwerkinterface (jeweils auf den beiden Servern) versiehst Du mit internen IP-Adressen aus einem gemeinsamen privaten Netz, zb 192.168.55.0/24, also das eine virtuelle Interface bekommt die 192.168.55.1, das andere auf dem anderen Rechner die 192.168.55.2 und wenn Du die Netzwerkmaske auf beiden dann auf 255.255.255.0 gesetzt hast, sollten die sich schon gegenseitig pingen können (sofern keine Firewall blockt).
CU, Peter
Danke für deine Antwort.
Ich frage jetzt einfach noch mal ganz blöd, damit ich die Begriffe besser zuordnen kann.
1. Im SCP habe ich unter dem Punkt Netzwerk bei beiden Servern die zweite Netzkarte aktiviert. Weitere Einstellungen sind nicht zu sehen. Ist mit NIC die Netzwerkkarte gemeint, die bei beiden Server die gleiche Bezeichnung hat?
2. killerbees19 hat ja ein Beispiel aufgezeigt. Das hatte ich unter /etc/network/interfaces so eingetragen wie er es oben angegeben hat. Ist das der richtige Ort?
3. Muss noch irgendwo anders etwas eingetragen werden?
Ansonsten kann es nur noch die Firewall sein.
Lg -
Ich habe noch eine Verständnisfrage. Habe in einem anderen Beitrag von Nic's gelesen und Bei dem kostenlosen VLan stand ja auch dass Nic's inklusive wären. Mir erschließt sich das alles irgendwie nicht. Habe auch schon Google befragt. Da habe ich aber nur Beiträge gefunden, wo zwischen heimischen Routern und PC's Verbindungen hergestellt werden.
Verstanden habe ich, dass Netcup mit dem VLan eine zweite Ethernetschnittstelle virtuell zur Verfügung stellt. Wenn ich früher zwei Rechner mit einem Netzkabel verbunden habe, dann musste ich auch interne IP's vergeben. So hatte ich auch die Antwort von
killerbees19 verstanden. Welche Funktion haben die Nic's und wo werden sie definiert?
-
Ich nehme mal an, Du hast jedem System eine eigene IP-Adresse fürs vLAN spendiert? Aus dem gleichen Subnetz? Firewall bedacht, sofern vorhanden?
Manchmal hilft auch ein Neustart des Servers, wenn man beim Testen der Netzwerkkonfiguration zu viel zerstört hat. Ginge natürlich auch im laufenden Betrieb, aber ein Reboot ist teilweise schneller.
Ich vermute auch die Firewall. Da muss ich nochmal schauen. Ansonsten 2 verschiedene IPS verwendet. Danke für deine Antwort
-
Oder direkt über die Datenbank mittels phpmyadmin:
Hello,
queries to run for fixing the issues:
CodeALTER TABLE `oc_share` ADD KEY `owner_index` (`uid_owner`) USING BTREE; ALTER TABLE `oc_share` ADD KEY `initiator_index` (`uid_initiator`) USING BTREE;
I updated my system to NC15 and still trying to fix some performance issues. I will write down my findings since the system is running.
-
Sorry!
Ihr habt mit Sudo recht.
Ich hatte einen Beitrag zu diesem Thema gefunden. Leider finde ich ihn nicht mehr.
Dort war der richtige Befehl für die PHP-Datei angegeben. Und mit dem klappte es damals.
Sollte ich den Artikel noch mal finden, werde ich mich noch mal melden. -
Nicht per ssh, sondern in eine php-datei speichern und ins Wurzelverzeichnis der Nextcloud laden.
-
Das wird so aber nicht im Webhosting funktionieren. Die Lösung von Mordor scheint mir die richtige zu sein.
LG
Alex
Bei mir hat es auf dem Webhosting genau so funktioniert. Auf dem Server habe ich es über die Konsole gemacht.
-
Ich hatte mich vertan eben mit dem Code. Habe nochmal nachgeschaut und meine Datei gefunden.
Ich habe folgendes als PHP-Datei hochgeladen und damit funktionierte es:Die Datei muss aber in das Wurzelverzeichnis der Nextcloud hochgeladen werden.
-
Hallo,
auf meinem EiWoMiSau Webspace habe ich Nextcloud am laufen und erhalte dort folgende Meldung:
Wenn mich nun aber per SSH auf die Shell verbinde, und den Befehl "occ db:convert-filecache-bigint" ausführe, erhalte ich nur ein "Permission denied" als Rückmeldung.
Wie kann ich das Problem lösen?
Danke.
Man kann den Befehl in eine PHP-Datei schreiben ins Wurzelverzeichnis von Nextcloud hochladen und dann aufrufen. Dann brauchst du nicht in die SSH, weil du da nicht die nötigen Rechte hast.
Die PHP, die erstellt wurde, beinhaltet
und liegt im Hauptverzeichnis der Nextcloud-Installation.
-
Normalerweise ist eth0 (bzw. ens3) das primäre Netzwerkinterface. Die vLAN Schnittstelle(n) wären dann eth1, eth2, ... (bzw. ens6, ens9, ...)
Schau mal, was bei Dir existiert: ip link
Erst mal eine Korrektur meiner Angabe: Ich war wieder zu schnell beim lesen. eth1 war nicht belegt. Dein Tipp hat mir schon mal aufgezeigt, dass es sich um ens6 handelt. Habe nach deiner Anleitung die IP's vergeben und auch ifup ens6 gemacht. Leider klappt das Pingen nicht.
Für heute mache ich erst mal Schluss.
Danke schon mal für deine Bemühungen