extDB3 Probleme auf Linux

Die extDB3.so ist eine Datei für die der Nutzer des Arma Servers Ausführungsrechte besitzen muss.

Daher die Frage ob die Rechte gesetzt sind.

Zitat von Henne079

Die extDB3.so ist eine Datei für die der Nutzer des Arma Servers Ausführungsrechte besitzen muss.

Daher die Frage ob die Rechte gesetzt sind.

Achso, schaue mal nach. Habe daran gar nicht gedacht

Edit: Ok der Benutzer hatte nur read und write rechte, habe ihm das recht zum ausführen auch mal gegeben, mal schauen was der Server jetzt so sagt.

Nope, immer noch der selbe Fehler wie gestern:

Hast du vielleicht noch eine Idee wie man dafür sorgen kann das er es nicht findet? Denn ich denke mal das er es nicht loaden wird haben wir behoben. Nur leider findet er es jetzt noch nicht mal mehr..

die .so Datei in lowcase hat nichts bewirkt genauso wenig wie sie in low case ins Hauptverzeichnis zu verschieben. Könnte mir noch vorstellen das ich sie in Capitalletter ins HV ziehen muss. Werde dies mal ausprobieren.

PS Danke für deine Hilfe bis her!

Edit: So, habe es jetzt ausprobiert. Wenn die Datei in Großbuchstaben im HV ist findet er sie. Dann meckert extDB aber rum das er die .ini nicht findet. Probiere deshalb mal die .ini ebenfalls in das Hauptverzeichnis zu packen.

Was für Rechte sind der Datei gesetzt und wem gehört diese?

Zitat von Henne079

Was für Rechte sind der Datei gesetzt und wem gehört diese?

Die Datei gehört dem Nutzer mit dem ich auch den A3 Server starte. Die rechte für den Nutzer sind lesen, schreiben und ausführen.

Ich sehe gerade, du hast versucht die Datei umzubenennen.

Die Datei muss extDB3.so heißen und befindet sich am besten im extDB3 Verzeichniss.

Die Config muss extdb3-conf.ini heißen und sich ebenfalls im extDB3 Verzeichniss befinden.

Im addons Verzeichniss im extDB3 Verzeichniss muss sich die extdb3.pbo befinden.

Also so wie es auch ist, wenn man extDB3 downloadet.

Hast du vielleicht Version 1.032 von extDB3 installiert?

Nutze Version 1.031.

Ansonsten mache eine neue frische saubere Installation vom ganzem Arma Server.

So habe jetzt noch etwas rumprobiert.

wenn die .so Datei im extdb Ordner ist findet der Server sie nicht.

wenn die .so im Hauptverzeichnis ist die .ini aber nicht findet er zwar die .so aber die .ini nicht.

wenn die .so und .ini im Hauptverzeichnis ist findet er beide kann sich aber warum auch immer nicht mit dem Server verbinden. InGame sagt er aber immernoch er kann es nicht laden.

wenn ich beide Dateien wieder in den extdb order tue und ihn @extDB3 nenne statt @extdb3 gibt er mir folgende Fehler aus:

Und InGame sagt er mir: extDB failed to load, please contact an administrator

Mir fällt langsam echt nichts mehr ein was ich tun kann..

In der Konsole sagt er mir er hat es geladen und kann sich nur nicht mit der DB verbinden, aber ich kann mich ja mit dem selben Nutzer über Navicat 12 verbinden.

Da es Arma ist würde ich sagen ich glaube der Konsole mehr, heißt extdb ist geladen kann sich aber nicht mit der DB verbinden. Teste jetzt mal in der .ini die Ip einmal durch 127.0.0.1 und durch localhost zu ersetzen.

Zitat von Henne079

Ich sehe gerade, du hast versucht die Datei umzubenennen.

Die Datei muss extDB3.so heißen und befindet sich am besten im extDB3 Verzeichniss.

Die Config muss extdb3-conf.ini heißen und sich ebenfalls im extDB3 Verzeichniss befinden.

Im addons Verzeichniss im extDB3 Verzeichniss muss sich die extdb3.pbo befinden.

Also so wie es auch ist, wenn man extDB3 downloadet.

Hast du vielleicht Version 1.032 von extDB3 installiert?

Nutze Version 1.031.

Ansonsten mache eine neue frische saubere Installation vom ganzem Arma Server.

Alles anzeigen

Hey, ja hatte ich aber hab es wieder so gemacht wie es war. die .pbo hab ich kleingeschrieben da er sie sonst nicht erkennt (die .pbo kommt normal großgeschrieben).

Ich probiere jetzt erstmal noch meine 2 Lösungen und wechsel dann zur 1.031 nutze aktuell die 1.020 - linux fixed glaube ich, da wir das damals schon mal hatten das er mit der aktuellsten Version nicht klar kommt.

So, also die IP zu localhost oder zu 127.0.0.1 zu ändern hat auch nicht geholfen.

Werde jetzt mal auf die 1.301 wechseln, hoffentlich funktioniert die.

So extdb ist drauf meine .ini sieht so aus:

[Main]
Version = 1

Randomize Config File = false
;; Randomizes Config File after loading.
;;   Recommend to turn on, if you have enabled filepatching on arma.

Allow Reset = false
;; Allows 9:RESET, usefull for development work

Thread = 0;
;; Option to force number of worker threads for extDB3.
;;   Auto = 0, Min = 2, Max = 6

[Log]
Flush = true;
;; Flush logfile after each update.
;;    Option really only usefull if running DEBUG BUILD


[altislife]
IP = 127.0.0.1
Port = 3306
Username = ****
Password = ****
Database = altislife

Die extDB Version wird aufjedenfall gefunden, aber leider nicht geladen:

mit ldd extDB3.so hab ich herausgefunden das ihm libz.so.1 fehlt.

werde es mal installieren und die .so mit chmod wieder anpassen (hatte ich nämlich vergessen wie ich gerade gesehen habe )

Also: Paket ist installiert, und der Benutzer hat rechte die .so Datei auszuführen. Der Server kann extDB laden aber sich nicht mit der DB verbinden. Hast du diesbezüglich auch ein paar Ideen? Denn der Benutzername, das Passwort ist richtig und der DB Name auch. Und über Navicat 12 kann ich mich ja auch anmelden und die DB bearbeiten. Der Nutzer hat auch alle rechte.

Also fangen wir mal an.

1. Linux achtet auf Groß- und Kleinschreibung und dichtet sich nicht irgendwas hin so wie Windows. Daher ist es wichtig die Dateien entsprechend zu benennen, oder den Namen der Dateien einfach zu lassen. Denn normal sind die Dateien so benannt, dass es funktioniert.

2. Du schreibst: gibt er mir folgende Fehler aus

15:36:43 "---------------------------------------------------------------------"
15:36:43 "---------------------------------------------------------------------"
sh: 1: objdump: not found
15:36:43 CallExtension loaded: extDB3 (/home/arma3/steamcmd/arma3/@extDB3/extDB3.so) [▒▒_▒S▒]
15:36:43 "extDB3 Loaded"
15:36:43 "---------------------------------------------------------------------"
15:36:43 "---------------------------------------------------------------------"

Da steht ja aber: CallExtension loaded: extDB3

Also ist es kein Fehler, sondern eine Erfolgsmeldung. Denn so soll es sein.

3. Die Meldung: sh: 1: objdump: not found stammt von dem Script den du nutzt um den Server zu verwalten. Diese Meldung sieht man hier öfters. Da ich das Script nicht nutze und mir dafür eigene Scripts geschrieben habe weiß ich jetzt nicht auswendig warum die Meldung geworfen wird.

Solltest du aber soweit ignorieren können. Denn der Server läuft ja.

4. Je nach der Einstellung der Datenbank und der Firewall, musst du den Datenverkehr innerhalb des Servers erst freigeben. Ansonsten kann der Server natürlich nicht auf die Datenbank zugreifen.

5. Das fehlende Paket hast du inzwischen installiert?

6. Die Version 1.031 von extDB3 funktioniert einwandfrei. Habe bisher keinerlei Probleme damit gehabt und wir nutzen diese schon sehr lange.

Also:

Zu 1. Ja ich weiß habe inzwischen ja alles so das es läuft.

Zu 2. Habe in meinem Letzten Post doch gar nicht geschrieben das es eine Fehlermeldung ist?

Zu 3. Okay, gut dann weiß ich wenigstens wo die her kommt.

Zu 4. Okay werde mich dies bezüglich schlauch machen.

Zu 5. Ja wie schon geschrieben habe ich dies bereits installiert (Glaube da ich soviel schreibe hast du gewisse teile überlesen )

Zu 6. Ja aktuell läuft extDB3 ja ganz ok er/es verbindet sich nur nicht mit der DB..

So habe herausgefunden, dass sich der Benutzer nicht über localhost sondern nur über Remote verbinden kann.

Habe jetzt mal etwas gemacht das zwar nicht besonders sicher ist aber hoffentlich die Lösung ist. Die Verbindung mit dem Nutzer Root zu probieren. Und es hat geklappt.

Ich bedanke mich daher für Eure/Deine Hilfe, jetzt muss ich nur noch schauen warum sich der eigentliche Nutzer nicht über localhost verbinden kann und dies ändern.

Zitat von MauGi_LP

. . .

Zu 2. Habe in meinem Letzten Post doch gar nicht geschrieben das es eine Fehlermeldung ist?

. . .

Zitat von MauGi_LP

. . .

wenn ich beide Dateien wieder in den extdb order tue und ihn @extDB3 nenne statt @extdb3 gibt er mir folgende Fehler aus:

1. Fehlermeldung

15:36:43 "---------------------------------------------------------------------"

15:36:43 "---------------------------------------------------------------------"

sh: 1: objdump: not found

15:36:43 CallExtension loaded: extDB3 (/home/arma3/steamcmd/arma3/@extDB3/extDB3.so) [▒▒_▒S▒]

15:36:43 "extDB3 Loaded"

15:36:43 "---------------------------------------------------------------------"

15:36:43 "---------------------------------------------------------------------"

. . .

Alles anzeigen

War zwar nicht der letzte Post, aber einige zuvor.

Zitat von MauGi_LP

. . .

mit ldd extDB3.so hab ich herausgefunden das ihm libz.so.1 fehlt.

. . .

werde es mal installieren

. . .

Daher die Nachfrage ob du es zu dem Zeitpunkt schon installiert hast.

Zitat von MauGi_LP

So habe herausgefunden, dass sich der Benutzer nicht über localhost sondern nur über Remote verbinden kann.

Habe jetzt mal etwas gemacht das zwar nicht besonders sicher ist aber hoffentlich die Lösung ist. Die Verbindung mit dem Nutzer Root zu probieren. Und es hat geklappt.

Ich bedanke mich daher für Eure/Deine Hilfe, jetzt muss ich nur noch schauen warum sich der eigentliche Nutzer nicht über localhost verbinden kann und dies ändern.

Weiß zwar nicht was du da eingestellt hast, aber vielleicht hast du localhost für den Nutzer auf der Blacklist?

Der root Nutzer ist nicht dafür gedacht, diesen Standardmäßig zu nutzen.

Wenn sich aber der root verbinden kann, liegt es weniger an der Verbindung an sich, sondern eher an mangelnden Rechten.

Daher stelle doch die Rechte ein und nutze einen anderen Nutzer.

Zitat von Henne079

War zwar nicht der letzte Post, aber einige zuvor.

Dann tut mir meine Unglückliche Wortwahl leid.

Zitat von Henne079

Der root Nutzer ist nicht dafür gedacht, diesen Standardmäßig zu nutzen.

Ich weiß, war ja jetzt nur zu test zwecken und wird so schnell wie möglich wieder geändert.

Zitat von Henne079

Wenn sich aber der root verbinden kann, liegt es weniger an der Verbindung an sich, sondern eher an mangelnden Rechten.

Eigentlich sollte der Nutzer alle rechte haben die er brauch.. werde den Nutzer mal löschen und neu anlegen.