Ми courier-a трябва да го играе POP3/IMAP сървър.
Все пак ползвай IMAP когато може, по-приятно е '>

[Цитат]

Не ползвам postfixadmin, но все пак като webmail съм убеден че няма да работи, използвай squirrelmail-a, инсталира се просто с копиране и се настройва с малко ръчкане с един perl-скрипт, дето сичко си пита (на мен ми отне 10 мин първия път).

Колкото до проблема apache-php-mysql - там съм доста бос и едва ли мога да съм полезен. От това, което си написал ми се струва, че пак имаш проблем с local socket/tcp:

Цитат

[Sat Feb 11 19:56:02 2006] [error] PHP Warning:  mysql_real_escape_string(): Can't connect to local MySQL server through socket '/var/run/mysql/mysql.sock' (13) in /web/functions.inc.php on line 131

Най-безболезнено ми се види ако вземеш пак да подкараш нещата (с този юзер) да работят през сокет... естествено без да затриваш постигнатото за 127.0.0.1 '>
Разбира се може и да греша - пак повтарям бос съм по темата. Успех! '>

[Цитат]

Цитат

root@mailer:~# mysql -h 127.0.0.1 -u postfix -p Enter password: ERROR 2003 (HY000): Can't connect to MySQL server on '127.0.0.1' (111) Да всички операции работят в самия mysql

Аз не бих казал, че са много работещи тези операции. Доколкото ти огледах conf-a на mysql-a, мисля, че той слуша за мрежови заявки (все пак го провери това, че не съм много навътре с mysql-a), предполагам остава юзера да получи право да се логва... ще трябва да поразпиташ google, успех и да споделиш резултата. '>

Дай да видим /etc/postfix/mysql_virtual_alias_maps.cf примерно.
Аз съм пуснал връзката по tcp, честно казано нямам идея как да опиша сокета в .cf файл на postfix-a.

Всъщност сигурен ли си, че postfix-a ползва сокет? С mysql -h 127.0.0.1 -u postfix -p дали отново влизаш? А някакви простички операции с базата работят ли от името на този user?
use <mail-db_name>;
select * from <ime-na-njakoja-tablica>;

Може би иде реч за грешки и в другите .cf файлове. Та ако искаш дай тяхното съдържание. Все пак погледни mysql-a преди това (и аз си патих с MySQL-а  и неговото виждане за localhost). Всъщност под localhost за MySQL се разбира връзка през сокет, а при 127.0.0.1 - връзко по tcp, порт 3306. Та ако си създал юзера, дето ще се връзва да има права от localhost, а не от 127.0.0.1 това може да ти е проблем, все пак погледни и с netstat дали mysql-a слуша на 127.0.0.1:3306
успех! '>
П.С.: Изглежда ми, че ти работи mysql поддръжката в postfixa, като не бях я активирал, имах доста екзотични съобщения за непознати протоколи или методи из логовете си. '>

Огледай си mydomain и myhostname в main.cf на postfix-a.
Стойностите им трябва да са това, което се очаква да се види "отвън". В случая външното IP на машината, която извършвa NAT-a трябва да се resolve-ва до myhostname в конфигурацията на postfix-a отзад.

Погледни MTU-то.
Почети как се решава проблема с iptables, 1 ред е. Съжалявам, но в момента не ми се намира време да изровя решението. '>
Успех! '>

Тук е обяснено подробно:
http://pptpclient.sourceforge.net/howto-fedora-core-4.phtml

Интересно...  Аз пък точно под тези "Greetings!" намерих линкове към въпросните тестове на портове... '>
И отговорите бяха ок, хвана ми 2-та отворени порта, друго не намери, което беше според очакванията ми '>

Ами ти си си го казал още в темата.
Настройваш squid, забраняваш forward-a на gateway-a и си готов.
Относно настойката на squid, има сума документация в интернет. На този сайт също има чудесна статия, потърси.
Все пак само за протокола - не съм уверен, че това което искаш е най-безболезнения и правилен вариант. Всъщност издири статията от сайта, мисля, че няма да сбъркаш ако се придържаш към нея, различава се от твоята идея, но пък е писана от човек, дето разбира повече от теб и мен за тези неща. '>

Успех!

Eдин път като си нагласиш правилата на iptables, можеш да ги запишеш с
service iptables save
ако пък оплескаш нещо се връщаш към запазеното състояние с
service iptables restore

Kолкото до разрешаването на ip_forward, имаш си нарочна променлива за целта, погледни в /etc или /etc/sysconfig за файл sysctl.conf, в него търсиш
net.ipv4.ip_forward = 0
и го променяш на
net.ipv4.ip_forward = 1

Happy rebooting ;-)

Интересно ми се види резултата и за utp, все пак той е по-често използвания протокол за днс-заявки, т.е.:
netstat -atunp | grep named
Може би не е от това, но допиши си номерата на мрежите, по-специално 192.168.0/24 на 192.168.0.0/24, струва ми се по-правилно, иначе може би bind-a си се оправя и така.
Първия днс сървър в forwarders си няма PTR запис, сигурно ли е, че е валиден? Ако не си убеден, по-добре използвай и втория dns-server на Спектър Нет, те поне грешка нямат '>
А това, че са ти на ACCEPT политиките в iptalbes е чудесно, но само ако някое правило преди него не реже пакетите.

Файла за обратната зона за вътрешната ти мрежа изглежда еднакъв с файла named.local, да не би просто да си го копирал? '>
В reverse трябва да опишеш ип-адреси и съответстващите им имена, типа на записа е PTR:
1   IN PTR gateway
2   IN PTR ivan.server.com.
3   IN PTR dragan
(като завършиш името с точка не се разширява с име на домейна)
Направи си и файл в който да са ти "правите" записи т.е. отляво имената:
gateway IN A 192.168.0.1
ivan       IN A 192.168.0.2
dragan.server.com. IN A 192.168.0.3
(тука пак играе далаверката с точката)

и двете зони ги описваш в named.conf

И последно предположение:
Аз съм с Fedora и при мен тя се стартира в различна коренова директория, виж дали и при теб не иде реч за chroot и ти да си конфигурираш един named.conf, a bind-a да чете друг, примерно при мен единия е заврян в /var/named/chroot/etc/named.conf, а другия си виси в /etc/named.conf, сега втория е просто линк към първия, но преди време това си беше отделен файл и полудях докато открия защо нещата в единия (онзи в /etc) се прочитат при рестартиране, а при релоад се прочиташе другия '>

Успех!

[Цитат]

Цитат (poisoner @ Дек. 29 2005,17:54)

слагам ги в authorized_keys2 щото е версия 2 на протокола, ще  пробвам довечера и с 1. Но то нали може да му се зададе -2 и да знае че става въпрос за втора версия и да чете от authorized_keys2. Или съм в грешка? едит: ама то ся се сетих че в ссхд_конф е зададено ~/.ssh/authorized_keys, за 2 не е зададен, така че може и да не го намира. Както и да е де, ше пробвам довечера и ше видим.

authorized_keys2 е име на файла, въпрос на вкус е как ще го кръстиш - не е проблем и authorized_keys8, идеята е в sshd.conf  да фигурира вярно име на файл.

Успех!

В случая няма нужда от DG, не става дума за трафик между мрежи. Но идеята за карта на дъното, както и за евентуално нещо друго на дъното, което пречи на настоящата карта е интересна. Не знам как е при Slack-a, не съм го ползвал, Fedora принципно ми открива новия хардуер доста читаво, но ако изключа kudzu, то мисля че това няма да се случи. дано това е някаква насока. Нямам опит нито със Слак, нито с тази карта.

[Цитат]

Ползвам postfix и това там се реализира направо елементарно (със sender_bcc_map), все пак се радвам, че не го ползвам '>
Признавам, че ми стана интересно и поразпитах малко google, та попаднах на това:

Цитат

How do I keep a copy of all incoming and outgoing mail messages? Answer: Set QUEUE_EXTRA to "Tlog\0" and QUEUE_EXTRALEN to 5 in extra.h. Recompile qmail. Put ./msg-log into ~alias/.qmail-log. You can also use QUEUE_EXTRA to, e.g., record the Message-ID of every message: run      | awk '/^$/ { exit } /^[mM][eE][sS][sS][aA][gG][eE]-/ { print }' from ~alias/.qmail-log.

Вижда ми се доста дървено, и не знам дали върши работа, но все пак е в faq на qmail: http://cr.yp.to/qmail/faq/admin.html#copies