Debian 11 clean install script
Das sagt:
grommunio-admin exmdb user1@domain.xx store get
internetarticlenumber 33
messagesizeextended 7108469 6.78 MiB
displayname user1name
creationtime 133119387740000000 2022-11-03 09:46:14
displaytypeex 0
outofofficestate 0
normalmessagesizeextended 7093943 6.77 MiB
assocmessagesizeextended 14526 14.2 kiB
- Edited
nochmal eine kleine Nickligkeit am Rande: Ich habe jetzt das Debian Paket grommunio-index nochmal komplett gelöscht (purge). Dort gibt es auch noch 2 issues mit dem systemd file (grommunio-index.service).
- das Paket wird statisch installiert (keine INSTALL section, gewollt?)
- ExecStart soll dann /usr/sbin/grommunio-index-run.sh laden (SuSe location) , das script wird aber in /usr/bin/grommunio-index-run.sh (Debian) installiert - insofern startet da ohne Änderungen eh nix
br br
Hmm .. also zum Fehlerhaften verhalten.. Kein schimmer was er da nicht mag.
Vielleicht noch mal frisch machen ist ja eh noch am testen wa? :-).
Zum Fehlerhaften SystemD-File erstmal ein fix
systemctl edit grommunio-index.service
und das hier da rein
[Service]
ExecStart=/usr/bin/grommunio-index-run.shDanach kannste ihn auch aktivieren mittels systemctl enable grommunio-index.service
Auch wenn das solange der Fehler besteht nicht viel hilft :P
@mwilliams meld dich doch mal bitte.. auch gern per mail oder irc :-).
- Edited
crpb
Ja, danke Dir, klar, das habe ich schon für mich geändert aber das muss ja irgendwie ins offizielle Paket fürs Debian repo rein! Kann ich das irgendwo 'offiziell' einkippen? (git?). Mit dem aktivieren über enable gehts damit aber noch nicht:
systemctl enable grommunio-index
The unit files have no installation config (WantedBy=, RequiredBy=, Also=,
Alias= settings in the [Install] section, and DefaultInstance= for template
units). This means they are not meant to be enabled using systemctl.
Possible reasons for having this kind of units are:
• A unit may be statically enabled by being symlinked from another unit's
.wants/ or .requires/ directory.
• A unit's purpose may be to act as a helper for some other unit which has
a requirement dependency on it.
• A unit may be started when needed via activation (socket, path, timer,
D-Bus, udev, scripted systemctl call, ...).
• In case of template units, the unit is meant to be enabled with some
instance name specified.Das mit dem 'mal frisch' machen ist sicherlich die Ultima ratio - jedoch geht es mir darum, einen möglichst nachvollziehbaren und robusten Debian Installationsprozess zu erreichen, der einen produktiv nutzbaren grommunio mail server erzeugt und vor allem nicht mit jedem grommunio update repariert/modifiziert werden muss - davon scheinen wir - nun ja - aktuell doch noch etwas entfernt von zu sein :-/
Ich bin jetzt mal die letzten drei meiner snapshots zurück gegangen - ohne Erfolg. Ich nutze eine Openstack Cloud mit dem Debian 11 openstack image und habe die Manual installation Anleitung sowie das Debian grommunio-setup script verwendet. Bislang bin ich noch nicht an dem Punkt, dass dreimal ausführen des grommunio-setup.sh dreimal exakt das gleich Ergebnis ergibt; insbesondere updates einzelner packages über das off. repo haben immer noch Seiteneffekte .... etwas mehr regression wäre vor Veröffentlichung schon wünschenswert - soweit mal mein ganz pers. Erfahrungsfeedback in a nutshell.
Aber na ja - kommt zeit, kommt laufendes Debian grommunio
br br
Versuch dir mal die drei ``` anzugewöhnen für "pastes" :-).
also meine tests sind bis jetzt nur auf vmware mit ner preseed die so ca 320 pakete nach reboot hat.
Von daher sollte das eigtl. auch dann mit dem openstack-image passen.
Ansonsten sinds fast die gleichen pakete wie es mir scheint :-).
curl https://cdimage.debian.org/cdimage/cloud/bullseye/latest/debian-11-generic-amd64.json 2>/dev/null|jq '.items[].data.packages|values[]|.name' |wc -lIch kann so leider nicht nachvollziehen was gerade bei dir kaputt ist. Deswegen würde ich jetzt zumindest noch mal den redo empfehlen um einfach alles auszuschließen.
Ansonsten können wir das auch gerne via IRC #grommunio (irc.debian.org) genauer diagnostizieren. Hier ist das ein wenig schwierig mit dem hin und her.
Apropos Offiziell reinkippen. Leider ist der "build"-Prozess nicht mit drin aber schau mal hier.
https://github.com/grommunio/grommunio-index
- Edited
Soooooo - der grommunio-indexer scheint jetzt in meiner Debian Installation endlich zu gehen ... was ist das Problem:
exmdb-provider verwendet als default eine ip Adresse [::1]:5000. Diese ist per default in meinem Debian image in /etc/hosts als ip6-localhost eingetragen. 'netstat -tulpen' sagt denn auch, dass es nur auf [::1]:5000 einen offenen Port gibt, NICHT jedoch für localhost:5000 (ie 127.0.0.1:5000). Soweit so gut.
grommunio-indexer wiederum hat (fest ein-compiliert ?!) einen default Parameter exmdb=localhost:5000 und hat wiederum keine eigene config Datei (?!), wo man dies anpassen kann. Es bliebe also nur eine Anpassung in /etc/gromox/exmdb_provider.cfg. Gemäß 'man 4gx exmdb_provider.cfg' kann man dort nur einen Parameter 'listen_ip' definieren (kein DNS?!?) und dort eine ipv6 Adresse ODER eine or 'v4-mapped address' (ie eg FFFF::127.0.0.1) angeben. Damit wären dann aber alle möglichen anderen Configs betroffen, die den exmdb provider nutzen.
Um das jetzt zum laufen zu bekommen, bleibt als schnelle Lösung nur, grommunio-index-run.sh anzupassen
In Zeile 28 die Option "-e ip6-localhost" ergänzen
grommunio-index "$1" "${maildir}" -o "${web_index_path}/${username}/index.sqlite3"
grommunio-index -e ip6-localhost "$1" "${maildir}" -o "${web_index_path}/${username}/index.sqlite3"
Wenn ich da nicht etwas grds übersehe, ist das aus meiner Sicht - nun ja - ein wenig robuste Herangehensweise: Variable Definitionen in /etc/hosts treffen auf statische DNS configs auf der einen und wenig flexible IP Adress Definitionen auf der anderen Seite, mal (begrenzt) änderbar in einer config Datei, mal (begrenzt) änderbar nur als Kommandozeilenparameter - unschön. Damit sind Aufwand im späteren produktiven Betrieb und den Anpassungen der configs vorprogrammiert.
Kann man so machen, muss man aber nicht.....
Sollte ich allerdings was übersehen haben, so freue ich mich über jeden besseren Vorschlag ....
Br br
Das localhost nicht immer 127.0.0.1 ist, dürfte an Optimierungen im Debian liegen. Hatte das Problem bei der letzten Installation aber beim postfix.
- Edited
Morsche,
hab mir grad des debian-11-generic-amd64.tar.xz von https://cloud.debian.org/images/cloud/bullseye/latest/ geladen und mal im qemu mit ner grml-iso geladen weil ich jetzt zu faul war da auch noch mein ssh-kram zu integrieren.. egal..
In dem Image ist /etc/hosts ich sag jetzt mal NORMAL. Und würde wohl dann auch so funktionieren.
Und laut https://cloud.debian.org/images/cloud/ wird das Generic ja für OpenStack empfohlen. Oder welches nutzt du?
EDIT: naja man erkennts so halb :P
- Edited
Das ist in der Tat merkwürdig, soweit ich das Konstrukt im Debian verstanden habe werden alle ipv6 Adressen die :::1 sind auf 127.0.0.1 gleichermaßen umgesetzt. Das sollte also eigentlich reichen und funktionieren.
Tatsächlich funzt es auch bei mir, obwohl ich auch nichts habe was offiziell auf 127.0.0.1:5000 lauscht sondern eben nur auf :::1:5000
Sieht bei mir dann so aus:
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 82307/sshd: /usr/sb
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 98373/master
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 914/nginx: master p
tcp 0 0 0.0.0.0:8443 0.0.0.0:* LISTEN 914/nginx: master p
tcp 0 0 127.0.0.1:11332 0.0.0.0:* LISTEN 88128/rspamd: main
tcp 0 0 127.0.0.1:11333 0.0.0.0:* LISTEN 88128/rspamd: main
tcp 0 0 127.0.0.1:11334 0.0.0.0:* LISTEN 88128/rspamd: main
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 884/mariadbd
tcp 0 0 0.0.0.0:587 0.0.0.0:* LISTEN 98373/master
tcp 0 0 127.0.0.1:6379 0.0.0.0:* LISTEN 783/redis-server 12
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 914/nginx: master p
tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 914/nginx: master p
tcp6 0 0 ::1:5555 :::* LISTEN 292591/midb
tcp6 0 0 ::1:33333 :::* LISTEN 292475/event
tcp6 0 0 :::22 :::* LISTEN 82307/sshd: /usr/sb
tcp6 0 0 :::24 :::* LISTEN 292421/delivery-que
tcp6 0 0 :::25 :::* LISTEN 98373/master
tcp6 0 0 :::443 :::* LISTEN 914/nginx: master p
tcp6 0 0 :::8443 :::* LISTEN 914/nginx: master p
tcp6 0 0 :::10080 :::* LISTEN 292853/http
tcp6 0 0 :::993 :::* LISTEN 292476/imap
tcp6 0 0 :::995 :::* LISTEN 292422/pop3
tcp6 0 0 ::1:11332 :::* LISTEN 88128/rspamd: main
tcp6 0 0 ::1:11333 :::* LISTEN 88128/rspamd: main
tcp6 0 0 ::1:11334 :::* LISTEN 88128/rspamd: main
tcp6 0 0 ::1:5000 :::* LISTEN 292853/http
tcp6 0 0 ::1:6666 :::* LISTEN 292358/timer
tcp6 0 0 :::10443 :::* LISTEN 292853/http
tcp6 0 0 :::587 :::* LISTEN 98373/master
tcp6 0 0 :::110 :::* LISTEN 292422/pop3
tcp6 0 0 :::143 :::* LISTEN 292476/imap
tcp6 0 0 :::80 :::* LISTEN 914/nginx: master p
tcp6 0 0 :::8080 :::* LISTEN 914/nginx: master pUnd dazu die /etc/hosts
127.0.0.1 localhost
# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters- Edited
Den kleinen aber feinen Unterschied macht, dass Deine Zeile
::1 localhost ip6-localhost ip6-loopback
'localhost' enthält - fehlt bei mir. Füge ich das ein, gehts auch. Ich habe jetzt nochmal eine jungfräuliche VM mit dem Image geladen, da fehlt localhost auch ....
O Mann
Das Image ist das Image meines cloud Providers, ist grundsätzlich auch das Debian generic cloud image, as ist aber managed über cloud-init und anscheinend wird da was geändert in diversen config Files. Ich schaue gerade in die cloud-init Logs was da genau passiert....
- Edited
Gehen wir also das nächste Debian Thema an: grommunio-archive und das nette Programm 'indexer' (s.o.)
Hat jemand noch eine Idee oder Information, wie man zu dem Tool 'indexer' kommt, welches da in diversen scripts so locker verwendet wird?
... Beantworte ich mal selbst: grommunio-archive braucht das zusätzliche Paket 'sphinxsearch', da ist der drin ...
BR br
Ich glaube archive, files, meet und chat haben wir bisher nicht aufgenommen. wenn du für archive ne lösung hast wärs cool wenn du die hier zur Verfügung stellst oder bei grosser Lust als Pull Request gegen das Repo stellst :-)
wenn Ichs hinkriege natürlich gerne - aber das scheint kein Selbstläufer zu sein - ich bin mir nicht sicher wieviele grommunio-archive zB ausserhalb der appliance am laufen haben - gibt doch einige Beiträge im Forum dazu, die Schwierigkeiten beschreiben. Im Moment hänge ich an der Frage, dass ich gar kein Archive GUI hochbekomme (error 404). Auch habe ich fpm pools für archive, die nicht starten wollen...
Fragen über Fragen .....
Na ich werd die Tage auch mal schauen. Ich hab eher noch das Problem dass der indexer läuft und auch sagt er stellt den index neu her für mein Postfach aber finden tu ich nix in der WebApp. Aber ich denk ich bin nur zu doof 