Здравствуйте! Есть старенький почтовый сервер с postfix+courier-imap, встал вопрос об апгрейде и выборе софта под него. С MTA я определился - postfix и останентся, а вот с IMAP - вопрос - что выбрать - оставить courier или поставить dovecot. Колеблюсь между простотой courier и функциональностью dovecot. Также планирую перенести конфиги в sql, чтобы рулить из postfixadmin. Что скажете? Также присутствует проблема больших .maildir с ~30000+ писем, говорят что dovecot с этим справляется лучше.

Перемещено beastie из general

Здравствуйте.
Имею следующий трабл. Есть ubuntu 1004, на ней samba BDC крутится. Вчера решил через apt-get обновить ядро. Ядро обновилось, все хорошо. Но после перезагрузки словил:
Kernel panic: Unable to mount root fs on unknown-block (0,0)
Подумал на initrd, пересобрал, тоже самое. Полез в grub загружать ядро вручную. И увидел следующую вещь - после команды:
linux /vmlinuz-2.6.32-32-generic-pae
имя initrd образа меняется на initrd.img-2.6.32-32-generic-pae.. , т.е. с 2 точками в конце. Добавил эти две точки в grub menuentry, ядро загрузилось. Вопрос: это баг или фича и что дальше с этим делать, ибо grub.cfg теперь править нельзя и это было временное решение?

З.Ы. новое ядро юзать пока не стал, а то фиг их знает, откуда точки :-)

Здравствуйте

Столкнулся с проблемой. Есть установленный postfix 2.5.5, устанавливали и настраивали до меня. Имеется следующая проблема: относительно медленно отсылаются письма на разные сервера, в частности на mail.ru и yandex.ru. Для примера, 3-х мегабайтное письмо на mail.ru уходит ~5 минут, примерно столько же принимается. При этом speedtest.net рапортует о исходящем канале в 17 мегабит и входящем в 8. Tcpdump показывает значительные задержки после получения ACK от mail.ru и посылкой очередной порции данных, например:
09:21:05.988606 IP mxs.mail.ru.smtp > 192.168.0.253.56466: . ack 194032 win 65535 <nop,nop,timestamp 190983090 315567529>
09:21:06.812529 IP 192.168.0.253.56466 > mxs.mail.ru.smtp: . 194032:204168(10136) ack 1 win 5840 <nop,nop,timestamp 315567530 190981429>
09:21:06.815660 IP mxs.mail.ru.smtp > 192.168.0.253.56466: . ack 195480 win 65535 <nop,nop,timestamp 190983917 315567530>
09:21:06.815805 IP mxs.mail.ru.smtp > 192.168.0.253.56466: . ack 196928 win 65535 <nop,nop,timestamp 190983917 315567530>
09:21:06.815909 IP mxs.mail.ru.smtp > 192.168.0.253.56466: . ack 198376 win 65535 <nop,nop,timestamp 190983917 315567530>
09:21:06.816079 IP mxs.mail.ru.smtp > 192.168.0.253.56466: . ack 199824 win 65535 <nop,nop,timestamp 190983917 315567530>
09:21:06.816166 IP mxs.mail.ru.smtp > 192.168.0.253.56466: . ack 201272 win 65535 <nop,nop,timestamp 190983917 315567530>
09:21:06.816311 IP mxs.mail.ru.smtp > 192.168.0.253.56466: . ack 202720 win 65535 <nop,nop,timestamp 190983918 315567530>
09:21:06.816325 IP mxs.mail.ru.smtp > 192.168.0.253.56466: . ack 204168 win 65535 <nop,nop,timestamp 190983918 315567530>
09:21:07.456567 IP 192.168.0.253.56466 > mxs.mail.ru.smtp: . 204168:207064(2896) ack 1 win 5840 <nop,nop,timestamp 315567587 190981661>
09:21:07.456574 IP 192.168.0.253.56466 > mxs.mail.ru.smtp: . 207064:217200(10136) ack 1 win 5840 <nop,nop,timestamp 315567588 190981662>09:21:05.988606 IP mxs.mail.ru.smtp > 192.168.0.253.56466: . ack 194032 win 65535 <nop,nop,timestamp 190983090 315567529>
09:21:06.812529 IP 192.168.0.253.56466 > mxs.mail.ru.smtp: . 194032:204168(10136) ack 1 win 5840 <nop,nop,timestamp 315567530 190981429>
09:21:06.815660 IP mxs.mail.ru.smtp > 192.168.0.253.56466: . ack 195480 win 65535 <nop,nop,timestamp 190983917 315567530>
09:21:06.815805 IP mxs.mail.ru.smtp > 192.168.0.253.56466: . ack 196928 win 65535 <nop,nop,timestamp 190983917 315567530>
09:21:06.815909 IP mxs.mail.ru.smtp > 192.168.0.253.56466: . ack 198376 win 65535 <nop,nop,timestamp 190983917 315567530>
09:21:06.816079 IP mxs.mail.ru.smtp > 192.168.0.253.56466: . ack 199824 win 65535 <nop,nop,timestamp 190983917 315567530>
09:21:06.816166 IP mxs.mail.ru.smtp > 192.168.0.253.56466: . ack 201272 win 65535 <nop,nop,timestamp 190983917 315567530>
09:21:06.816311 IP mxs.mail.ru.smtp > 192.168.0.253.56466: . ack 202720 win 65535 <nop,nop,timestamp 190983918 315567530>
09:21:06.816325 IP mxs.mail.ru.smtp > 192.168.0.253.56466: . ack 204168 win 65535 <nop,nop,timestamp 190983918 315567530>
09:21:07.456567 IP 192.168.0.253.56466 > mxs.mail.ru.smtp: . 204168:207064(2896) ack 1 win 5840 <nop,nop,timestamp 315567587 190981661>
09:21:07.456574 IP 192.168.0.253.56466 > mxs.mail.ru.smtp: . 207064:217200(10136) ack 1 win 5840 <nop,nop,timestamp 315567588 190981662>

Приведу master.cf:
# Postfix master process configuration file. For details on the format
# of the file, see the master(5) manual page (command: «man 5 master»).
#
# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================
smtp inet n - n - - smtpd
# -o content_filter=clamav
#submission inet n - n - - smtpd
# -o smtpd_enforce_tls=yes
# -o smtpd_sasl_auth_enable=yes
# -o smtpd_client_restrictions=permit_sasl_authenticated,reject
#smtps inet n - n - - smtpd
# -o smtpd_tls_wrappermode=yes
# -o smtpd_sasl_auth_enable=yes
# -o smtpd_client_restrictions=permit_sasl_authenticated,reject
#628 inet n - n - - qmqpd
pickup fifo n - n 60 1 pickup
cleanup unix n - n - 0 cleanup
qmgr fifo n - n 300 1 qmgr
#qmgr fifo n - n 300 1 oqmgr
tlsmgr unix - - n 1000? 1 tlsmgr
rewrite unix - - n - - trivial-rewrite
bounce unix - - n - 0 bounce
defer unix - - n - 0 bounce
trace unix - - n - 0 bounce
verify unix - - n - 1 verify
flush unix n - n 1000? 0 flush
proxymap unix - - n - - proxymap
smtp unix - - n - 20 smtp
# When relaying mail as backup MX, disable fallback_relay to avoid MX loops
relay unix - - n - - smtp
-o fallback_relay=
# -o smtp_helo_timeout=5 -o smtp_connect_timeout=5
showq unix n - n - - showq
error unix - - n - - error
retry unix - - n - - error
discard unix - - n - - discard
local unix - n n - - local
virtual unix - n n - - virtual
lmtp unix - - n - - lmtp
anvil unix - - n - 1 anvil
scache unix - - n - 1 scache

И «немного о себе»:
Linux samba 2.6.25.4 #6 SMP Tue Jul 15 12:27:32 MSD 2008 i686 Intel(R) Pentium(R) D CPU 2.80GHz GenuineIntel GNU/Linux

top - 09:34:16 up 14 days, 14:57, 6 users, load average: 0.10, 0.22, 0.20
Tasks: 345 total, 1 running, 344 sleeping, 0 stopped, 0 zombie
Cpu(s): 8.6%us, 1.5%sy, 0.0%ni, 86.9%id, 2.5%wa, 0.2%hi, 0.3%si, 0.0%st
Mem: 3367840k total, 3069140k used, 298700k free, 84508k buffers
Swap: 4016224k total, 1428k used, 4014796k free, 2398084k cached

Собственно вопрос - это есть недостатки конфига самого постфикса, в чем я лично сомневаюсь, или самой ОС и в частности tcp стека? Или я что то упустил?

Всем доброго времени суток.

Заитересовал меня тут один вопрос, по поводу skype. Есть у меня на работе человек, который общается по skype. Он работает в офисе, сидит за NAT, nat'ом занимается iptables. Есть другой человек, с Yota - соответственной тоже за NAT. Они нормально общаются по skype, даж видео пролезает. Внимание вопрос - какой хелпер в iptables из серии nf_conntrack отвечает за корректное преобразование udp трафика skype? Т.е. кто помогает iptables разобраться что пришедший udp пакет на адрес шлюза и на порт 12345 надо за NAT перенаправить на комп со skype?

Здравствуйте. Заставили тут меня обстоятельства прикручивать к Linux-серверу, раздающему интернет, второй канал в интернет через yota. Был куплен модем Samsung SWC-U200, прикручен к серверу по средствам madwimax, настроены правила маршрутизации, NAT и прокси. И была замечена странная особенность - при работе клиентов через прокси скорость такая, как и заявлено в yota - 4-5 Мбит (если верить speedtest.net). А при работе через NAT скорость с клиентов не превышает 500-800 Кбит/с. Кстати если воткнуть модем в компьютер с winxp - скорость тоже не выше 500 Кбит/с. Настройки, которыми прикручивалась yota:

iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o wimax0 -j TCPMSS --clamp-mss-to-pmtu

iptables -t nat -A POSTROUTING -o wimax0 -s 192.168.0.0/24 -j MASQUERADE

ip route add $NET dev wimax0 table yota
ip route add 192.168.0.0/24 dev eth0 table yota
ip route add default via $GW dev wimax0 table yota
ip rule add fwmark 100 table yota
ip rule add to $IP table yota
ip rule add from $IP table yota

iptables -t mangle -A PREROUTING -s 192.168.0.0/24 -d ! 192.168.0.250 -m conntrack --ctstate NEW -j CONNMARK --set-mark 100

iptables -t mangle -A PREROUTING -j CONNMARK --restore-mark

Собсно вопрос, ЧЯДН, и почему прокси забирает траффик от yota с приличной скоростью, а клиенты через NAT не «развивают» скорость?

Здравствуйте. Имеется Subj - материнка Intel DG33TL и Slackware 12.1 на ней. Собственно вопрос - можно ли на ней средствами lm_sensors получить что-то большее, чем температуру ядер процессора? Ядро 2.6.24.5, lm_sensors 3.0.3. Правда ядро пропатчено grsecurity, так что sensors-detect сканит только SMBUS чипы, на остальных обламывается. На SMBUS чипов не находит. При загрузке дистрибутивного ядра находится 1 чип на Super I/0:
> Trying family `National Semiconductor'... Yes
> Found `Nat. Semi. PC8374L Super IO Sensors'
> (but not activated)
При modprobe lm85 команда sensors все равно выдает только температуру ядер...
Ходят слухи что у этой матери чипы могут быть в самом южном мосте (ICH9R) или где то в экзотическом месте на SMBUS. Возможности загрузить оффтопик и посмотреть everest'ом, что ж за чип мониторинга там трудится нет. Если кто нить мониторил на этой материнке напряжения и вентиляторы, поделитесь опытом и драйвером :-)

Здравствуйте, имею следующий вопрос: каким образом засчитывается трафик в счетчик интерфейса, допустим eth1 - т.е. по команде ifconfig eth1 выводиться кол-во полученных/переданных байт. Вопрос в том, что попадает в этот счетчик - т.е. arp заголовки, кадры LLC и прочая служебная информация помимо полезной нагрузки или нет?
И какими образом собирается эта статистика: драйвер сетевой карты отдает эти цифры или как то еще?
Просто вопрос возник в связи с тем, что на шлюзе под linux была настроена netams со сбором статистики через libpcap и цифры переданного и полученного траффика шлюзом за день разняться с выводом команды ifconfig примерно мб на 10-15. Ifconfig показывает всегда больше, чем netams. В принципе не много, но за месяц набегает.
Также цифры, выдаваемые netams разняться со статистикой провайдера мегабайт на 20-50 (5-8%) в день. Провайдерская статистика также показывает больше - что тоже не есть хорошо.
Отсюда еще один вопрос - а учитывает ли libpcap служебную информацию или нет?

З.Ы. на том конце у провайдера стоит cisco - поэтому скорей всего он считает через netflow...

З.З.Ы. Вообше то хочется разобраться - это у меня что-то не так настроено или провайдер подвирает? Просто iptables столько мб за день дропнуть не может - проверял, ошибок в канале вроде тож нет - ifstat и ifconfig показывют ошибки по нулям.....

>>>

Здравствуйте, имею следующий вопрос о том, как лучше организовать авторизацию пользователей в squid. Сейчас авторизация идет через basic хелпер ncsa. Возникла необходимость разбить пользователей на группы и раздавать инет согласно группам. Если сделать примерно так:

#Autentification
auth_param basic program /usr/squid/libexec/ncsa_auth /usr/squid/etc/passwd
auth_param basic children 15
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 2 hours
auth_param basic casesensitive off

acl user_url dstdomain .domain1.com
acl sec_url dstdomain .domain2.com

acl group_admins proxy_auth user1 user4 REQUIRED
acl group_users proxy_auth user2 REQUIRED
acl group_sec proxy_auth user3 REQUIRED

#HTTP Access
http_access allow manager localhost
http_access deny manager

http_access allow group_admins
http_access allow group_users user_url
http_access allow group_sec sec_url

Имхо тут плохо то, что proxy_auth здесь больше одного раза и squid будет терзать хелпер до появления первого OK - хотелось бы узнать, а вообше можно ли так делать, когда proxy_auth упоминается больше 1-го раза - не повлияет ли это на стабильность и т.д. Еще при использовании такой схемы был замечен глюк в IE7 -при попытке зайти куда либо спрашивает пароль 3 раза, потом пускает, возможно тоже из-за 3 proxy_auth, хотя в FF такого не замечено.
Или же есть еще 1 схема:

acl mydomain_site dstdomain .mydomain.ru
external_acl_type unix_group %LOGIN /usr/squid/libexec/check_group
acl auth proxy_auth REQUIRED
acl inet_full external unix_group inet-full
acl inet external unix_group inet

http_access allow auth mydomain_site
http_access allow inet_full
http_access allow inet user_url

Тут уже proxy_auth один раз, но неудобство в том, что приходись заводить пользователей дважды - в /etc/passwd и в passwd squid'а. И с этой схемой глюков с IE не замечено. В общем, хотелось бы выяснить, какая схема лучше. Сам склоняюсь к первой, т.к. проще пользователей заводить.....

>>>