Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.
Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Postfix und cyrus "reden" nicht richtig miteinande
Achso, sag das doch ;-)
Sorry bin noch Linux-anfänger
Das funktioniert jetzt auch, super danke nochmals
Jetzt hab ich nur noch ein Problem: seit der Neuinstallation funktioniert der Apache2 nicht mehr (aber da werd ich erst mal googlen und bei Bedarf einen neuen Tread aufmachen.
ja, der Mailserver funzt. nur noch eine Frage:
fetchmail loggt ja alle 2 Minuten (awaking und sleeping), das wird auf Dauer ein bissl viel, oder?
Wie kann ich das ändern, daß zb nur bei Fehlern geloggt wird?
ich habe wieder das read time out problem auf dem lmtp *seufz
aber was habe ich eigentlich geändert?
mit apt-get wollte ich meinen server updaten. Allerdings gab es probleme mit dem paket kvirc.
ich denke mal kvirc ist wohl ein irc client, den ich nicht unbedingt brauche.
dann hat apt auch 17 pakete ersetzt (xfree, genau weiß ich es nicht mehr)
und apache2-prefork durch apache-worker ersetzt.
mein apache läuft jetzt zwar, aber der mailserver nicht mehr.
alle mails hängen bei postfix im queue
Status:
connect to /var/lib/imap/socket/lmtp[/var/lib/imap/socket/lmtp]: read timeout
ich versteh hier nix mehr, ehrlich gesagt. *seufz
vielleicht kann sich ja einer von euch zusammenreimen, was hier passiert ist.
an den postfix, cyrus conf hab ich nix geändert.
fetchmail läuft noch im daemon modus und holt all 2 minuten die mails von gmx ab.
In der message log steht wie schon einmal gehabt der cyrus dberror.
Dieser Fehler trat das erste mal auf, während das Update via Apt lief.
hast du SUSEconfig ausgeführt ? und wenn ja, hoffentlich hast du den Schalter deaktiviert, das SUSE den postfix konfiguriert!! Sonst war alles für die Katz. Dieses SuSEconfig schraubt dann nämlich an deinen conf's rum.
Sieh mal nach *.rpmnew,*.rpmorig,*.rpmsave,*.YastSave,*.SuSEconfig Dateien im /etc und /etc/postfix Ordner.
also ne meldung von apt gab es eigentlich nicht (bis auf das er kein update machen kann wegen kvirc). also habe ich kvirc gelöscht
dann ging das update.
wenn ich in der apt.log reinschaue und auch in die messages dann sehe ich, das der erste fehler von cyrus (dberror) in dem zeitraum aufgetreten ist, als das update lief. nicht am anfang und nicht am ende des updates sondern mittendrin. das update dauerte iemlich lange, weil es viele pakete waren, aber man kann sagen, daß so ziemlich mittig im update der erste fehler auftrat. am ende des updates führt apt doch auch suseconfig usw aus.
falls es so wäre wie du befürchtest (das suse die postfix konfiguration umgeändert hat) müßte dann der fehler nicht am ende des updates aufgetreten sein?
in /etc/postfix gibt es u.a. folgende dateien:
main.cf
main.cf.2004-07-08 (zu diesem zeitpunkt lief der mailserver noch)
main.cf.suseconfig
main.cf.default
main.cf.rpmnew
canonical.rpmnew
was macht dich so sicher, daß suse den postfix verorgelt hat?
in messages gibt es wieder diesen dberror von cyrus.
vielleicht stimmt beim cyrus was nicht. hmm. was aber wieder komisch ist:
mails vom client ins internet verschicken funzt.
das abholen via fetchmail bis in die postfix queue auch
also kann das doch gar nicht soooo schlimm sein was suse oder apt oder wer auch immer da angerichtet hat.
da fällt mir noch was ein, ich habe ja die conf dateien von cyrus postfix und fetchmail vorsichtshalber gesichtert. aber auch das zurückkopieren dieser dateien mit anschließendem reload/restart von cyrus und postfix hilft nicht weiter, der fehler bleibt.
SuSEconfig setzt Rechte von Dateien anhand von /etc/permissions*
SuSEconfig mach das was in /etc/sysconfig/* steht, wenn dort deine Einträge von postfix, fetchmail, etc standen werden die immer wieder eingesetzt. Wir haben aber nicht via Yast konfiguriert, sondern nach guter alter Linux-Methode direkt an den configs.
die main.cf-2004* ist die letzt funktionierende Konfig, die zurücksichern.
die rpmnew Dateien entstehen bei Neu-Installation eines rpm. Du solltest nach jedem update mal rcrpmconfigcheck aufrufen, das zeigt dir welche configs geändert wurden.
bei apt kannst du abstellen, das SuSEconfig aufgerufen wird, dann steuerst du das selber: /etc/apt/apt.conf.d/post.conf ist die Datei (Scripts::Options::RunPostScript false
ich tippe mal, das irgendwelche Rechte von SuSEconfig verbogen wurden.
Wenn du die Dateien ermittelt hast kannst du in /etc/permissions.local dafür sorgen, das diese Dateien DEINE Rechte erhalten (z.Bsp. cdrecord, cdrdao werden immer ohne SUID gesetzt,...)
Prüfe das nochmal.
mit sdiff -s alt neu kannst du die betroffenen configs ja mal checken.
das apt-update hat dir nicht neue db* Pakete installiert ?
in der y2log.suseconfig steht unter anderem:
Starting SuSEconfig, the SuSE Configuration Tool...
Running in verbose mode.
Running in full featured mode.
Reading /etc/sysconfig and updating the system...
skipping modules
postdrop: warning: unable to look up public/pickup: No such file or directory
postdrop: warning: unable to look up public/pickup: No such file or directory
postdrop: warning: unable to look up public/pickup: No such file or directory
postdrop: warning: unable to look up public/pickup: No such file or directory
postdrop: warning: unable to look up public/pickup: No such file or directory
postdrop: warning: unable to look up public/pickup: No such file or directory
postdrop: warning: unable to look up public/pickup: No such file or directory
Finished.
postdrop: warning: unable to look up public/pickup: No such file or directory
weiter unten:
Starting SuSEconfig, the SuSE Configuration Tool...
Running in verbose mode.
Running module postfix only
Reading /etc/sysconfig and updating the system...
Executing /sbin/conf.d/SuSEconfig.postfix...
Rebuilding /etc/aliases.db.
No changes for /etc/postfix/master.cf
Setting up postfix local as MDA...
Setting SPAM protection to "off"...
No changes for /etc/postfix/main.cf
Finished.
und das hier:
Starting SuSEconfig, the SuSE Configuration Tool...
Running in verbose mode.
Running module postfix only
Reading /etc/sysconfig and updating the system...
Executing /sbin/conf.d/SuSEconfig.postfix...
No changes for /etc/postfix/master.cf
Setting up cyrus-imapd via lmtp as MDA...
[1m *** WARNING ***
adding postfix user to group mail
*** WARNING ***
[m Setting SPAM protection to "off"...
No changes for /etc/postfix/main.cf
Finished.
jetzt, wo du die permissions ansprichst fällt mir ein, daß er beim updaten rechte geändert hat.
zb:
Starting SuSEconfig, the SuSE Configuration Tool...
Running in verbose mode.
Running module permissions only
Reading /etc/sysconfig and updating the system...
Executing /sbin/conf.d/SuSEconfig.permissions...
Checking permissions and ownerships - using the permissions files
/etc/permissions.d/apache2
/etc/permissions.d/cups-client
/etc/permissions.d/kdebase3
/etc/permissions.d/kdelibs3
/etc/permissions.d/kpopup
/etc/permissions.d/mailman
/etc/permissions.d/postfix
/etc/permissions.d/squid
/etc/permissions.d/susehelp
/etc/permissions.d/tetex
/etc/permissions
/etc/permissions.easy
/etc/permissions.local
setting /var/lib/texmf/ to root:root 1755. (wrong permissions 0755)
setting /var/lib/texmf/db/ to root:root 1755. (wrong permissions 0755)
setting /var/adm/backup to root:root 0700. (wrong permissions 0755)
Finished.
ich glaube das waren noch mehr, aber ich weiß nicht in welche log er das geschrieben haben könnte.
ad yast:
wenn no_mail_config gesetzt ist, werden keine neuen postfix configs erzeugt, OK
ad apt:
nicht in apt.conf sondern in der psot.conf
bei einem kernel-update soll SuSEconfig laufen wegen mkinitrd und evtl lilo. Das ist sicherer.
ad permissions.local:
da schreibst du DEINE Rechte Änderungen rein. Diese datei wird immer am Schluss aufgerufen und überschreibt die Eingaben aus permissions.{easy,secure,paranoid}
Auf welchem Level dein System arbeitet wird in yast eingestellt. Du solltest secure wählen.
zu deinem Problem:
Setting up cyrus-imapd via lmtp as MDA...
da wurden cyrus configs geändert. Vielleicht wurde die Zeile mit dem prefork=1 geändert. Bzw. den Pfad zu dem lmtp.
Ich weiss jetzt nicht mehr ob dein mailserver mit deliver=cyrus oder via lmtp zuletzt funktioniert hat.
CYRUS.CONF PRÜFEN ...
Wenn du deinen Mailserver neu startest sind diese services erforderlich:
rcpostfix start
rcfetchmail start
rcsaslauthd start
rccyrus start
rcamavis start (falls du das nutzt)
die Meldungen von cyrus werden in /var/log/messages protokolliert
die Meldungen von postfix,fetchmail werden in /var/log/mail* protokolliert.
natürlich in der post.conf. hab ich ja auch so gemacht.
cyrus funktionierte via lmtp. deliver= cyrus könnte man aber später evtl auch probieren, wenn alle stricke reißen sollten. welches der beiden möglichkeiten hat denn vor bzw nachteile?
die permissions habe ich nun auf secure gestellt (war easy)
hier mal die cyrus.conf. der pfad zum lmtp war auch so eingestellt, als der mailserver lief (allerdings bin ich mir bei prefork=0 nicht sicher):
# standard standalone server implementation
START {
# do not delete this entry!
recover cmd="ctl_cyrusdb -r"
# this is only necessary if using idled for IMAP IDLE
# idled cmd="idled"
}
# UNIX sockets start with a slash and are put into /var/lib/imap/socket
SERVICES {
# add or remove based on preferences
imap cmd="imapd" listen="imap" prefork=0
# imaps cmd="imapd -s" listen="imaps" prefork=0
pop3 cmd="pop3d" listen="pop3" prefork=0
# pop3s cmd="pop3d -s" listen="pop3s" prefork=0
sieve cmd="timsieved" listen="sieve" prefork=0
# at least one LMTP is required for delivery
# lmtp cmd="lmtpd" listen="lmtp" prefork=0
lmtpunix cmd="lmtpd" listen="/var/lib/imap/socket/lmtp" prefork=0
# this is only necessary if using notifications
# notify cmd="notifyd" listen="/var/lib/imap/socket/notify" proto="udp" prefork=1
}
EVENTS {
# this is required
checkpoint cmd="ctl_cyrusdb -c" period=30
# this is only necessary if using duplicate delivery suppression
delprune cmd="cyr_expire -E 3" at=0400
# this is only necessary if caching TLS sessions
tlsprune cmd="tls_prune" at=0400
# Uncomment the next entry, if you want to automatically remove
# old messages of EVERY user.
# This example calls ipurge every 60 minutes and ipurge will delete
# ALL messages older then 30 days.
# enter 'man 8 ipurge' for more details