Postfix, pgsql will auf localhost connecten

[ath0]

Hallo,

ich hoffe das mir jemand einen Hinweis geben kann.
Ich bin gerade dabei meinen mailserver in einzelne jails zu teilen. Ich möchte DB und den rest den man für einen mailserver (also den mailserver selbst) benötigt trennen. Ich habe also zwei jails einmal die DB und dann den mail kram. Beim versenden von mails bekomme ich im maillog folgende meldung.

Feb 24 21:32:11 mail postfix/trivial-rewrite[2606]: warning: connect to pgsql server localhost: could not connect to server: Connection refused??Is the server running on host "localhost" (127.0.0.1) and accepting??TCP/IP connections on port 5432??could not create socket: Protocol not supported?
Feb 24 21:32:11 mail postfix/trivial-rewrite[2606]: warning: pgsql:/etc/postfix/virtual_alias_domains_maps.cf: table lookup problem
Feb 24 21:32:11 mail postfix/trivial-rewrite[2606]: warning: virtual_alias_domains lookup failure
Feb 24 21:32:11 mail postfix/trivial-rewrite[2606]: warning: pgsql:/etc/postfix/virtual_alias_domains_maps.cf: table lookup problem
Feb 24 21:32:11 mail postfix/trivial-rewrite[2606]: warning: virtual_alias_domains lookup failure

In der virtual_alias_domains_maps.cf steht folgendes

user = dbuser
password = password
host = 192.168.1.202
dbname = maildb
query = SELECT concat('@', target_domain ) FROM alias_domain WHERE concat('@', alias_domain) = '%s' AND active = '1'

Connecte ich via

psql -h 192.168.1.202 maildb dbuser

komme ich an die Datenbank.
Ich hatte anfänglich den host den ich zzt. noch in der hosts drin habe in der config drin, auch damit kann psql sich connecten.
Hat einer einen Tip wo postfix localhost raus lesen könnte?
Sorry das ich nicht die main.cf poste aber die ganze config poste ich aus paranoia lieber nicht.

EDIT: Abrufen der mails via dovecot läuft super.

 

[m4rkus]

Hallo,

ich glaube es liegt alleine an deiner "host"-Zeile: Laut http://www.postfix.org/pgsql_table.5.html sollte der Parameter nämlich "hosts" heißen. Würde erklären, warum der default-Wert (localhost) genommen wird.

Aber: Du schriebst, dass du PostgreSQL im Jail betreibst. Davon würde ich bei einer Mehrbenutzermaschine abraten. Meines Wissens musst du die Sicherheitsmechanismen in Bezug auf "Shared Memory" soweit aufweichen, dass die Jail-Funktionalität nicht mehr vollständig gegeben ist. Auf einem Desktop-Spielsystem, wo du nur selbst dran arbeitest, ist das aus meiner Sicht nach völlig i.O. und sehr praktisch. Auf einem Server würde ich persönlich die DB auf dem Host starten und entsprechend absichern, dass nur die Jails drauf zugreifen können (Stichwort: pg_hba.conf in Kombination mit pf).

Gruß
Markus

 

[ath0]

Hallo,

ich glaube es liegt alleine an deiner "host"-Zeile: Laut http://www.postfix.org/pgsql_table.5.html sollte der Parameter nämlich "hosts" heißen. Würde erklären, warum der default-Wert (localhost) genommen wird.

Ich denke das war der sanfte Hieb den ich brauchte, evtl. komme ich Heute noch dazu es zu probieren. Danke dafür!

Aber: Du schriebst, dass du PostgreSQL im Jail betreibst. Davon würde ich bei einer Mehrbenutzermaschine abraten. Meines Wissens musst du die Sicherheitsmechanismen in Bezug auf "Shared Memory" soweit aufweichen, dass die Jail-Funktionalität nicht mehr vollständig gegeben ist. Auf einem Desktop-Spielsystem, wo du nur selbst dran arbeitest, ist das aus meiner Sicht nach völlig i.O. und sehr praktisch. Auf einem Server würde ich persönlich die DB auf dem Host starten und entsprechend absichern, dass nur die Jails drauf zugreifen können (Stichwort: pg_hba.conf in Kombination mit pf).

Gruß
Markus

Ja das ich die jail löchrig machen musste stimmt. Ich halte eine Jail aber dennoch für eine gute idee denn ein wenig eingespeert ist immernoch eingespert auch wenn man sich aus dem Gefängniss frei buddeln kann braucht man dafür Zeit. Ich nutze jails immer häufiger einfach nur um Installationen zu kapseln gar nicht mal um die sicherheit zu erhöhen. In der vergangenheit sind meine Server immer erst sehr spät geupdatet worden um nichts kaputt zu machen. Jetzt nutze ich auf allen Rechnern ZFS und BEs und alles in jails zu kapseln erleichtert das update einer bestimmten Anwendung erheblich, da dies in einem Testumfeld geschehen kann. Ist man fertig wird die Jail von der spielwiese in die DMZ geschoben und beim booten werden die echten Daten reingemountet, und fertig.
In diesem Fall ist die pgsql jail aber immernoch sicher genug, da die jail nur via psql angesprochen werden kann und alle jails die verbindung in die Welt haben sind nicht nur Laufgitter ^^

Danke trotzdem für die anregung.

 

[ath0]

Ja das war es, host durch hosts austauschen hat es gebracht. Komischerweise erst nach dem ich das in allen cf s gemacht hatte. Bis dahin blieb der die Fehlermeldung die selbe. Kaum macht man es richtig funktioniert es!
Muss man wissen

Nochmal vielen Dank für die Hilfe

 

[m4rkus]

Schön das es jetzt geht.

Bzgl. der Jails: Meines Wissens nach gilt der nötige Parameter für alle Jails, so dass das Risiko weiter erhöht wird. In Testumgebungen und Einzelplatzsystemen spricht glaube ich nichts dagegen - produktiv würde ich jedoch eher auf dem Host arbeiten.

Gruß
Markus

 

[Yamagi]

Seit FreeBSD 9.2 oder irgendwo im den Dreh ist allow.sysvipc auf ein Jail begrenzt. Allerdings sind die Speicherbereiche weiterhin zwischen Host und allen Jails geteilt, es können also alle Jails mit der Option auf sie zugreifen. Dadurch kann es eventuell zum Ausbruch kommen. Nachdem mit Postgresql 9.3 der Bedarf an SysV-IPC schon drastisch eingedampft wurde, kommt vielleicht irgendwann ja die komplette Abschaffung.

 

[ath0]

Seit FreeBSD 9.2 oder irgendwo im den Dreh ist allow.sysvipc auf ein Jail begrenzt. Allerdings sind die Speicherbereiche weiterhin zwischen Host und allen Jails geteilt, es können also alle Jails mit der Option auf sie zugreifen. Dadurch kann es eventuell zum Ausbruch kommen. Nachdem mit Postgresql 9.3 der Bedarf an SysV-IPC schon drastisch eingedampft wurde, kommt vielleicht irgendwann ja die komplette Abschaffung.

Danke Yamagi, dann habe ich das gestern also richtig gelesen. Also alles im grünen Bereich