Hallo, ich habe in einem Benutzerverzeichnis .fetchmailrc liegen mit einem funktioinablen Eintrag. in /etc/ habe ich auch eine liegen. Der Dämon welcher läuft berücksichtigt aber nicht die des Users. Wo liegt mein Fehler? Danke. Igor
Hi, Igor Warneck <linux@daten-schleuder.de> wrote:
Hallo,
ich habe in einem Benutzerverzeichnis .fetchmailrc liegen mit einem funktioinablen Eintrag.
Ich vermute, dass dieser User _nicht_ root ist!?
in /etc/ habe ich auch eine liegen. Der Dämon welcher läuft berücksichtigt aber nicht die des Users.
Als welcher User laeuft denn fetchmail? Wird es von root gestartet? Dann vermute ich, dass fetchmail die ~/.fetchmailrc des Users, der es gestartet hat benutzt. ---8<--[Ausschnitt aus 'man fetchmail']-- Simply invoking fetchmail -d 900 will, therefore, poll all the hosts described in your ~/.fetchmailrc file (except those explicitly excluded with the `skip' verb) once every fifteen minutes. -->8---
Wo liegt mein Fehler?
Danke.
Igor
HTH Sven -- 2. My ventilation ducts will be too small to crawl through. --Peter Anspach's list of things to do as an Evil Overlord -------------------------------------------------------[rand. sig. #3]
Hi!
ich habe in einem Benutzerverzeichnis .fetchmailrc liegen mit einem funktioinablen Eintrag. in /etc/ habe ich auch eine liegen. Der D�mon welcher l�uft ber�cksichtigt aber nicht die des Users. Wo liegt mein Fehler?
der daemon wird mit -f /etc/fetchmailrc aufgerufen, nimmt also nur die im /etc/ verzeichnis. in z.B. /etc/ppp/ip-up kann man das aendern (nach fetchmail suchen). wuerde ich aber nicht tun, sondern die im /etc/ verzeichnis aendern. ciao T
Dr. Thorsten Brandau, Dienstag, 4. Mai 2004 15:23:
Hi!
ich habe in einem Benutzerverzeichnis .fetchmailrc liegen mit einem funktioinablen Eintrag. in /etc/ habe ich auch eine liegen. Der Dmon welcher luft bercksichtigt aber nicht die ^^ Zeichensätze sind was feines ;-) Bei mir steht hier ein hochgestelltes "IND".
des Users. Wo liegt mein Fehler?
der daemon wird mit -f /etc/fetchmailrc aufgerufen, nimmt also nur die im /etc/ verzeichnis.
... und das ist gut so [TM].
in z.B. /etc/ppp/ip-up kann man das aendern (nach fetchmail suchen). wuerde ich aber nicht tun, sondern die im /etc/ verzeichnis aendern.
Jein. Die User-Dateien sind individuell für jeden User gedacht, damit kann jeder User des Systems fetchmail mit seinen (und nur mit denen) Zugangsdaten individuell aufrufen - ggf. auch zusätzlich zum Daemon. Aus diesem Grund gehören in diese User-bezogene fetchmail-rc auch die Zugangsdaten dieses Users. -- Gruß MaxX 8-) Hinweis 1: PMs an diese Adresse werden automatisch vernichtet. Hinweis 2: Bitte unbedingt beachten: http://www.suse-etikette.de.vu
Hi!
liegen. Der D"mon welcher l"uft ber_cksichtigt aber nicht die ^^ Zeichens�tze sind was feines ;-) Bei mir steht hier ein hochgestelltes "IND".
bei mir steht da immer was anderes ;-) aber man gewoehnt sich an alles ;-))))
suchen). wuerde ich aber nicht tun, sondern die im /etc/ verzeichnis aendern.
Jein.
Die User-Dateien sind individuell f�r jeden User gedacht, damit kann
MMh. kann ich nur insofern zustimmen das es natuerlich abhaengig davon ist, wie der rechner konfiguriert ist. Man soll natuerlich nie von sich auf andere schliessen, bei mir moechte ich aber schon die mail von ALLEN benutzer regelmaessig holen (ueber einen cron-job), daher muss in der /etc/fetchmailrc alles stehen. Eigentlich moechte ich ja auch nicht, das ein benutzer aus dem netz heraus einfach seine private mail holt, schliesslich wuerde er dann z.T. diese mit der Firmenkennung wegschicken - die dadurch entstehenden komplikationen sind vielvaeltig und muessen hier nicht diskutiert werden. Das ist aber natuerlich einfach dadurch zu verhindern, das der benutzer sich nicht am mailserver einloggen kann. Fuer testzwecke ist das private .fetchmailrc sicherlich fein. Ich sehe da aber eine grosse potentielle Fehlerquelle fuer ein system ein .fetchmailrc aus einem user-verzeichnis heraus aufzurufen. Die Gefahr, das man es spaeter vergisst und wieder loescht ist einfach zu gross. Es kommt sicherlich in erster Linie auf die tatsaechliche Rechnerkonfiguration an, z.B. ob es sich um einen Router, ein Firmennetzerk, einen Privatrechner etc. handelt. Ein Backup das nur z.B. /etc und vielleicht /var/lib/named sichert ist sicherlich besser zu handeln als erst mal z.B. alle privaten Konfigurationsdateien zusammenzusammeln... ciao T
Dr. Thorsten Brandau, Mittwoch, 5. Mai 2004 07:48:
Hi!
liegen. Der D"mon welcher l"uft ber_cksichtigt aber nicht die ^^ Zeichenstze sind was feines ;-) Bei mir steht hier ein hochgestelltes "IND".
bei mir steht da immer was anderes ;-)
aber man gewoehnt sich an alles ;-))))
Ja?
suchen). wuerde ich aber nicht tun, sondern die im /etc/ verzeichnis aendern.
Jein.
Die User-Dateien sind individuell fr jeden User gedacht, damit kann
MMh. kann ich nur insofern zustimmen das es natuerlich abhaengig davon ist, wie der rechner konfiguriert ist. Man soll natuerlich nie von sich auf andere schliessen, bei mir moechte ich aber schon die mail von ALLEN benutzer regelmaessig holen (ueber einen cron-job), daher muss in der /etc/fetchmailrc alles stehen.
Das habe ich ja nicht verneint. Die /etc/fetchmailrc ist die allgemeine für alle User, die auch der Daemon nutzt. Diese kann aber nur von root geändert werden, Benutzer können so z.B. nicht ihr Passwort ändern oder private Accounts dazufügen. Dafür ist dann die persönliche fetchmailrc zuständig, wenn man denn das Abfragen privater Accounts erlauben will (verursacht in der Regel weniger Traffic als über ein Web-Portal, was ja sonst die Mitarbeiter machenwürden *g*).
Eigentlich moechte ich ja auch nicht, das ein benutzer aus dem netz heraus einfach seine private mail holt, schliesslich wuerde er dann z.T. diese mit der Firmenkennung wegschicken - die dadurch entstehenden komplikationen sind vielvaeltig und muessen hier nicht diskutiert werden.
Richtig, man muss ja auch nicht unbedingt private Mails am Arbeitsplatz zulassen.
Das ist aber natuerlich einfach dadurch zu verhindern, das der benutzer sich nicht am mailserver einloggen kann.
Fuer testzwecke ist das private .fetchmailrc sicherlich fein. Ich sehe da aber eine grosse potentielle Fehlerquelle fuer ein system ein .fetchmailrc aus einem user-verzeichnis heraus aufzurufen. Die Gefahr, das man es spaeter vergisst und wieder loescht ist einfach zu gross.
Und, was passiert dann?
Es kommt sicherlich in erster Linie auf die tatsaechliche Rechnerkonfiguration an, z.B. ob es sich um einen Router, ein Firmennetzerk, einen Privatrechner etc. handelt.
Ja, sicher. Auf meinem Privatrechner kann ich jederzeit root sein und meine Konfiguration nach Belieben ändern ;-)
Ein Backup das nur z.B. /etc und vielleicht /var/lib/named sichert ist sicherlich besser zu handeln als erst mal z.B. alle privaten Konfigurationsdateien zusammenzusammeln...
Ich würde aber auf einem System die Homeverzeichnisse auf jeden Fall auch sichern. Die sind eigentlich das Wichtigste. -- Gruß MaxX 8-) Hinweis 1: PMs an diese Adresse werden automatisch vernichtet. Hinweis 2: Bitte unbedingt beachten: http://www.suse-etikette.de.vu
Hi!
aber man gewoehnt sich an alles ;-))))
Ja?
Ja. oder aergerst du dich bei jedem tanken das der liter sprit (diesel) 1,80 DM kostet? :-(
Das habe ich ja nicht verneint. Die /etc/fetchmailrc ist die allgemeine f�r alle User, die auch der Daemon nutzt. Diese kann aber nur von root ge�ndert werden, Benutzer k�nnen so z.B. nicht ihr Passwort �ndern oder private Accounts dazuf�gen.
richtig. das finde ich auch gut so - der benutzer hat ja nichts mit dem firmenprovider zu tun. genauso wie nicht jeder mitarbeiter seinen eigenen "uplinkaccount" bekommt, bekommt er auch nicht die benutzerdaten beim uplink - in diesem falle der mailhost beim provider oder woanderst. der benutzer "sieht" nur seinen account und der unterscheidet sich vom uplink.
Daf�r ist dann die pers�nliche fetchmailrc zust�ndig, wenn man denn das Abfragen privater Accounts erlauben will (verursacht in der Regel weniger Traffic als �ber ein Web-Portal, was ja sonst die Mitarbeiter machenw�rden *g*).
wenn man das zulaesst ;-) ueber squid kann man so mache seite ausblenden oder gar nicht erst erlauben. fuer firmennetze wirklich gut.
Richtig, man muss ja auch nicht unbedingt private Mails am Arbeitsplatz zulassen.
warum dann private .fetchmailrc s?
ein .fetchmailrc aus einem user-verzeichnis heraus aufzurufen. Die Gefahr, das man es spaeter vergisst und wieder loescht ist einfach zu gross.
Und, was passiert dann?
man weiss nicht warum es nicht geht. wo es doch vorher so gut funktioniert hat. ist einfach eine fehlerquelle weniger.
Ja, sicher. Auf meinem Privatrechner kann ich jederzeit root sein und meine Konfiguration nach Belieben �ndern ;-)
"Ich bin root ich darf das" <- einer meiner lieblingssprueche. oder wie mit dem maedel das aus versehen mal root in "oot" umbenannt hat, und dann das t-shirt "Bow for me so I am oot" bekam ;-)
Ich w�rde aber auf einem System die Homeverzeichnisse auf jeden Fall auch sichern. Die sind eigentlich das Wichtigste.
tja, mache ich halt nicht. die datenverzeichnisse liegen woanders und jeder benutzer bekommt beim einrichten einen link aus seinem homedirectory dahin... daher kann ich die homes bequem loeschen ;-) spass beiseite, stimmt schon das man homes sichern sollte, aber nichtsdestotrozt finde ich das einfacher die konfigurationsdateien an einem ort - eben /etc zu haben. frueher war das sehr wuest, aber seit wenigen jahren ist das endlich schoen konsistent bei suse geworden und man finded (fast) alles unter /etc ... ciao T
Dr. Thorsten Brandau, Mittwoch, 5. Mai 2004 17:11:
Hi!
aber man gewoehnt sich an alles ;-))))
Ja?
Ja.
oder aergerst du dich bei jedem tanken das der liter sprit (diesel) 1,80 DM kostet? :-(
Ich kann mich dunkel an Zeiten erinnern, da hab ich 90 Pf dafür bezahlt. Da hab ich aber auch nur die Hälfte verdient (bzw. die gleiche Zahl wie heute, nur ein DM dahinter).
Das habe ich ja nicht verneint. Die /etc/fetchmailrc ist die allgemeine fr alle User, die auch der Daemon nutzt. Diese kann aber nur von root gendert werden, Benutzer knnen so z.B. nicht ihr Passwort ndern oder private Accounts dazufgen.
richtig. das finde ich auch gut so - der benutzer hat ja nichts mit dem firmenprovider zu tun. genauso wie nicht jeder mitarbeiter seinen eigenen "uplinkaccount" bekommt, bekommt er auch nicht die benutzerdaten beim uplink - in diesem falle der mailhost beim provider oder woanderst. der benutzer "sieht" nur seinen account und der unterscheidet sich vom uplink.
Dafr ist dann die persnliche fetchmailrc zustndig, wenn man denn das Abfragen privater Accounts erlauben will (verursacht in der Regel weniger Traffic als ber ein Web-Portal, was ja sonst die Mitarbeiter machenwrden *g*).
wenn man das zulaesst ;-) ueber squid kann man so mache seite ausblenden oder gar nicht erst erlauben. fuer firmennetze wirklich gut.
Naja, nicht schlecht. Aber man findet sowie so nie alles. Und im Internet nur erlaubte Seiten zuzulassen und alles andere zu sperren ist irgendwie auch blöd. Selbst Content-Filter sind nie Perfekt.
Richtig, man muss ja auch nicht unbedingt private Mails am Arbeitsplatz zulassen.
warum dann private .fetchmailrc s?
Wenn man es doch erlauben will. So wird keine Zeit sinnlos damit vergeudet, einen Weg an den Sperren vorbei zu finden (hast du alle kostenlosen hawaiianischen e-Mail-Provider mit Webmailer im Squidguard gesperrt?).
ein .fetchmailrc aus einem user-verzeichnis heraus aufzurufen. Die Gefahr, das man es spaeter vergisst und wieder loescht ist einfach zu gross.
Und, was passiert dann?
man weiss nicht warum es nicht geht. wo es doch vorher so gut funktioniert hat.
ist einfach eine fehlerquelle weniger.
Na gut.
Ja, sicher. Auf meinem Privatrechner kann ich jederzeit root sein und meine Konfiguration nach Belieben ndern ;-)
"Ich bin root ich darf das" <- einer meiner lieblingssprueche. oder wie mit dem maedel das aus versehen mal root in "oot" umbenannt hat, und dann das t-shirt "Bow for me so I am oot" bekam ;-)
Ich wrde aber auf einem System die Homeverzeichnisse auf jeden Fall auch sichern. Die sind eigentlich das Wichtigste.
tja, mache ich halt nicht. die datenverzeichnisse liegen woanders und jeder benutzer bekommt beim einrichten einen link aus seinem homedirectory dahin... daher kann ich die homes bequem loeschen ;-)
... und damit auch persönliche Einstellungen? Wenn da mal nicht irgendwann jemand dein Auto um eine Reifenbreite tiefer legt ...
spass beiseite, stimmt schon das man homes sichern sollte, aber nichtsdestotrozt finde ich das einfacher die konfigurationsdateien an einem ort - eben /etc zu haben. frueher war das sehr wuest, aber seit wenigen jahren ist das endlich schoen konsistent bei suse geworden und man finded (fast) alles unter /etc ...
Da gehören sie ja auch hin. Hab ich schon immer so, und dann ggf. einen Link von dem Ort aus, wo das Programm die Dateien vermutet (wenn es nicht anders geht). -- Gruß MaxX 8-) Hinweis 1: PMs an diese Adresse werden automatisch vernichtet. Hinweis 2: Bitte unbedingt beachten: http://www.suse-etikette.de.vu
participants (4)
-
Dr. Thorsten Brandau -
Igor Warneck -
Matthias Houdek -
Sven Pfeifer