Beiträge von bananenkiste

erledigt

Problem gelöst.

Ich habe zuerst wieder Leap 15.6 installiert.

Dort habe ich mit YAST auf den beiden M.2 SSDs jeweils eine 512MiB Partition eingetragen. Die auf /dev/nmve0n1 für /boot/efi, die andere wird nicht gemountet und liegt brach.

Über den verbleibenden Rest der beiden SSDs wurde dann das RAID1 zur Verwendung für das Betriebssystem aufgebaut.

Davon gingen 16GiB an SWAP und den Rest hat dann YAST automatisch aufgeteilt.

lsblk zeigt jetzt das hier:

NAME        MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
sda           8:0    0   7.3T  0 disk  
└─md1         9:1    0  14.6T  0 raid5 
  └─md1p1   259:8    0  14.6T  0 part  /home
sdb           8:16   0   7.3T  0 disk  
└─md1         9:1    0  14.6T  0 raid5 
  └─md1p1   259:8    0  14.6T  0 part  /home
sdc           8:32   0   7.3T  0 disk  
└─md1         9:1    0  14.6T  0 raid5 
  └─md1p1   259:8    0  14.6T  0 part  /home
nvme0n1     259:0    0 223.6G  0 disk  
├─nvme0n1p1 259:1    0   512M  0 part  /boot/efi
└─nvme0n1p2 259:2    0 223.1G  0 part  
  └─md0       9:0    0 223.1G  0 raid1 
    ├─md0p1 259:6    0    16G  0 part  [SWAP]
    └─md0p2 259:7    0 206.7G  0 part  /var
                                       /usr/local
                                       /tmp
                                       /srv
                                       /root
                                       /opt
                                       /boot/grub2/i386-pc
                                       /boot/grub2/x86_64-efi
                                       /.snapshots
                                       /
nvme1n1     259:3    0 223.6G  0 disk  
├─nvme1n1p1 259:4    0   512M  0 part  
└─nvme1n1p2 259:5    0 223.1G  0 part  
  └─md0       9:0    0 223.1G  0 raid1 
    ├─md0p1 259:6    0    16G  0 part  [SWAP]
    └─md0p2 259:7    0 206.7G  0 part  /var
                                       /usr/local
                                       /tmp
                                       /srv
                                       /root
                                       /opt
                                       /boot/grub2/i386-pc
                                       /boot/grub2/x86_64-efi
                                       /.snapshots
                                       /

Nach der Altdatenübernahme sind die Platten mit /home zu 32% belegt. Aber flott ist die Kiste.

Gruß,

die Bananenkiste

Hallo Foristen,

zur Ablösung meines bisherigen Produktiv-Servers (Bj 2017, jetzt auf Leap16 aktualisiert) habe ich gestern die neue Hardware bekommen.

32GB RAM, 2x 223GB SSD M.2 nvme RAID 1 für das Betriebssystem und 3x 8TB HDD RAID 5 für Daten.

SOHO Umfeld, 4 (vier) User

Betrieb gerne headless

Hauptaufgaben:

Mail (fetchmail>postfix>dovecot)

Datenablage

MariaDB

zentraler OCR Service für Netzwerk-Scanner

Die Platten kamen ohne Partitionierung. Das war mit YAST ja kein Problem. Da kamen Vorschläge und die habe ich wohl abgenickt.

Leap 16.0 bzw. agama kann keine RAIDs mehr einrichten. OKAY. In einem parallelen Terminal habe ich das erledigt, habe dabei aber nicht gut nachgedacht. Nach Empfehlung des Lieferanten (bekannter deutscher Server-Lieferant) habe ich 2 M.2 SSDs geordert, die das Betriebssystem auf einem RAID1 tragen sollen. Nur: wie soll ich die SSDs aufteilen?

SWAP wird doch nicht auf einem RAID liegen? Kann ich von einem RAID booten? Ist das überhaupt sinnvoll? In wie viele Partitionen muss ich den Rest aufteilen? Wie groß soll/muss ich die Partitionen machen?

Diese devices habe ich zur Verfügung:

für das Betriebssystem:

/dev/nvme0n1

/dev/nvme1n1

für die Daten:

/dev/sda \

/dev/sdb } RAID 5 /home

/dev/sdc /

Mit parted und mdadm kann ich jetzt einigermaßen umgehen. Nur das zu erstellende Layout ist mit nicht klar.

Könnte mir hierzu bitte jemand ein paar Hinweise geben?

Vielen Dank und Gruß,

die Bananenkiste

... noch als "gelöst" markiert.

Problem gelöst.

auth_username_format = xyz

Diese Variable bestimmt nicht, wie die Validierung erfolgen soll, sondern gibt an, was zur Validierung übergeben wird. Dovecot selbst schaut dann, dass es mit den Angaben klar kommt.

Daher ist das hier richtig:

auth_username_format = %{user | lower }

Das hatte ich falsch verstanden.

Jetzt muss ich nur noch die Konfigurationsdateien aufräumen. Aber 16.0 läuft jetzt!

Danke für die Beteiligung.

Gruß,

die Bananenkiste

Nachschlag:

Postfix Configuration Parameters

Postfix hängt den "@xxx.yz"-String an und man darf das nicht abschalten. Das muss schon vor meiner Aktualisierung so gewesen sein.

Ich muss offenbar dovecot dazu bringen, doch user@domain zu validieren.

Wie geht das?

Zitat von Hidalgo

und gebe dort wie oben auth_username_format = %n ein.

Du beschreibst hier die alte Syntax (dovecot < 2.4).

So sieht das in der neuen Syntax aus:

auth_username_format = %{user | username | lower }

Zudem schaust Du auf die falsche Stelle. Dovecot kann einen übergebenen user authentifizieren sofern er als blanker username übergeben wird. Die IMAP-Clients können sich ja anmelden.

Mein Problem besteht zwischen fetchmail bzw. sendmail > postfix > dovecot.

Fetchmail leitet ein mail an user "bananenkiste" weiter. Postfix macht daraus dann (neuerdings) "bananenkiste@meinserver.de". Und dadurch fällt dann dovecot auf den Bauch.

Hallo Foristen,

ich habe meinen Server von Leap 15.4 über 15.5 und 15.6 auf 16.0 aktualisiert.

Seitdem funktioniert der interne Mailtransport nicht mehr.

fetchmail > postfix > dovecot oder behelfsweise sendmail >postfix > dovecot

Den Zugriff der IMAP-Clients auf dovecot konnte ich bereits reparieren (Unterschiede in den config-files 2.3 vs 2.4). Die user können alle Mails in der gewohnten Form sehen. Es werden aber keine neuen Mails von draußen durchgereicht.

Die Mails werden hier intern schon immer über den user-namen, wie in der passwd angegeben, adressiert - nicht über username@domain.

In einem ersten Schritt habe ich sendmail > postfix getestet:

echo Testmail | /usr/sbin/sendmail \ bananenkiste
echo Testmail | /usr/sbin/sendmail \ bananenkiste@meinserver.de

Die Antwort im Log sieht IN BEIDEN FÄLLEN so aus:

dovecot[53767]: lmtp(55218): Connect from local
dovecot[53767]: auth: Debug: master in: USER        2672689164        bananenkiste@meinserver.de        protocol=lmtp
dovecot[53767]: auth(bananenkiste@meinserver.de): Debug: passwd: Performing userdb lookup
dovecot[53767]: auth: Debug: conn unix:auth-worker: Connecting
dovecot[53767]: auth: Debug: conn unix:auth-worker (pid=53765,uid=0): Client connected (fd=20)
dovecot[53767]: auth: Debug: conn unix:auth-worker (pid=53765,uid=0): Sending version handshake
dovecot[53767]: auth-worker: Debug: conn unix:auth-worker (pid=55219,uid=476): Server accepted connection (fd=8)
dovecot[53767]: auth-worker: Debug: conn unix:auth-worker (pid=55219,uid=476): Sending version handshake
dovecot[53767]: auth-worker: Debug: conn unix:auth-worker (pid=55219,uid=476): auth-worker<1>: Handling USER request
dovecot[53767]: auth-worker(bananenkiste@meinserver.de)<55264>: request [1]: Debug: passwd: Performing userdb lookup
dovecot[53767]: auth-worker(bananenkiste@meinserver.de)<55264>: request [1]: Debug: passwd: lookup
dovecot[53767]: auth: Debug: auth-worker: Worker sent process limit '30'
dovecot[53767]: auth-worker(bananenkiste@meinserver.de)<55264>: request [1]: passwd: unknown user
dovecot[53767]: auth-worker(bananenkiste@meinserver.de)<55264>: request [1]: Debug: passwd: Finished userdb lookup
dovecot[53767]: auth(bananenkiste@meinserver.de): Debug: passwd: Finished userdb lookup
dovecot[53767]: auth-worker: Debug: conn unix:auth-worker (pid=55219,uid=476): auth-worker<1>: Finished: user_unknown
dovecot[53767]: auth: Debug: userdb out: NOTFOUND        2672689164
dovecot[53767]: lmtp(55218): Disconnect from local: Logged out (state=READY)

Aus bananenkiste wird bananenkiste@meinserver.de

Damit scheitert die Authentifizierung über passwd.

Weiß jemand Rat?

Vielen Dank für Tipps.

Gruß,

Bananenkiste

Ich habe meinen Fehler gefunden, die Datenbank läuft wieder!

Ich hatte damals ProtectHome auf false gesetzt indem ich das wie unter 2) beschrieben gemacht hatte.

Zitat

# However, there are 2 methods how to customize this unit file:

#

# 1) Copy this unit file from /usr/lib/systemd/system to

# /etc/systemd/system and modify the chosen settings.

#

# 2) Create a directory named mariadb.service.d/ within /etc/systemd/system

# and place a drop-in file name.conf there that only changes the specific

# settings one is interested in.

#

Alles anzeigen

Allerdings hieß das dazu neu angelegte Verzeichnis nicht /etc/systemd/system/mariadb.service.d - es fehlte das .d am Ende.

Das habe ich eben ergänzt und schon gehts.

Preisfrage: Warum hat die Chose unter 15.2 funktioniert?

Danke Euch für die Hilfe!

matbhm das sind nur Links. Aber ich habe sie trotzdem mal umbenannt.

fileserver5:/etc/systemd/system # mv mysql.service mysql_.service
fileserver5:/etc/systemd/system/multi-user.target.wants # mv mysql.service mysql_.service

dann

fileserver5:/etc/systemd/system/multi-user.target.wants # systemctl start mysql
Failed to start mysql.service: Unit mysql.service failed to load properly: Is a directory.
See system logs and 'systemctl status mysql.service' for details.
fileserver5:/etc/systemd/system/multi-user.target.wants # systemctl start mariadb
Failed to start mariadb.service: Unit mariadb.service failed to load properly: Is a directory.
See system logs and 'systemctl status mariadb.service' for details.
fileserver5:/etc/systemd/system/multi-user.target.wants #

Keine Veränderung

Erst nach Umbenennung der letzten .service-Datei war die Reaktion eine andere (klar):

fileserver5:/usr/lib/systemd/system # mv mysql.service mysql_.service
fileserver5:/usr/lib/systemd/system # systemctl daemon-reload
fileserver5:/usr/lib/systemd/system # systemctl start mysql
Failed to start mysql.service: Unit mysql.service not found.
fileserver5:/usr/lib/systemd/system #

Das habe ich dann aber wieder zurückgedreht:

fileserver5:/usr/lib/systemd/system # mv mysql_.service mysql.service
fileserver5:/usr/lib/systemd/system # systemctl daemon-reload
fileserver5:/usr/lib/systemd/system # systemctl start mysql
Failed to start mysql.service: Unit mysql.service failed to load properly: Is a directory.
See system logs and 'systemctl status mysql.service' for details.
fileserver5:/usr/lib/systemd/system #