Re: непонятка с сетью

2016-03-19 Пенетрантность Andrei Lomov 
Andrei Lomov wrote:

> Прошу помощи.
> Есть роутер, к нему подключаю проводком нетбук с кубунтой 14.04, сеть
> работает (dhcp).

Вот еще syslog.

NetworkManager что-то мутит, сходу не могу понять, удалить его что-ли 
совсем:

Mar 18 08:31:09 kolya-347 kernel: [1.423889] r8169 :03:00.0 eth0: 
RTL8168g/8111g at 0xc9c5e000, fc:aa:14:96:a0:d2, XID 0c000800 IRQ 29
Mar 18 08:31:09 kolya-347 kernel: [1.423893] r8169 :03:00.0 eth0: 
jumbo features [frames: 9200 bytes, tx checksumming: ko]
Mar 18 08:31:09 kolya-347 NetworkManager[813]:SCPlugin-Ifupdown: devices 
added (path: /sys/devices/pci:00/:00:09.0/:03:00.0/net/eth0, 
iface: eth0)
Mar 18 08:31:09 kolya-347 NetworkManager[813]:SCPlugin-Ifupdown: device 
added (path: /sys/devices/pci:00/:00:09.0/:03:00.0/net/eth0, 
iface: eth0): no ifupdown configuration found.
Mar 18 08:31:09 kolya-347 NetworkManager[813]:  (eth0): carrier is OFF
Mar 18 08:31:09 kolya-347 NetworkManager[813]:  (eth0): new Ethernet 
device (driver: 'r8169' ifindex: 2)
Mar 18 08:31:09 kolya-347 NetworkManager[813]:  (eth0): exported as 
/org/freedesktop/NetworkManager/Devices/0
Mar 18 08:31:09 kolya-347 NetworkManager[813]:  (eth0): device state 
change: unmanaged -> unavailable (reason 'managed') [10 20 2]
Mar 18 08:31:09 kolya-347 NetworkManager[813]:  (eth0): bringing up 
device.
Mar 18 08:31:09 kolya-347 NetworkManager[813]:  (eth0): preparing 
device.
Mar 18 08:31:09 kolya-347 NetworkManager[813]:  (eth0): deactivating 
device (reason 'managed') [2]
Mar 18 08:31:09 kolya-347 NetworkManager[813]:  Added default wired 
connection 'Wired connection 1' for 
/sys/devices/pci:00/:00:09.0/:03:00.0/net/eth0
Mar 18 08:31:09 kolya-347 kernel: [4.798686] r8169 :03:00.0 eth0: 
link down
Mar 18 08:31:09 kolya-347 kernel: [4.798706] r8169 :03:00.0 eth0: 
link down
Mar 18 08:31:09 kolya-347 kernel: [4.798724] IPv6: ADDRCONF(NETDEV_UP): 
eth0: link is not ready
Mar 18 08:31:11 kolya-347 NetworkManager[813]:  (eth0): carrier now ON 
(device state 20)
Mar 18 08:31:11 kolya-347 NetworkManager[813]:  (eth0): device state 
change: unavailable -> disconnected (reason 'carrier-changed') [20 30 40]
Mar 18 08:31:11 kolya-347 NetworkManager[813]:  Activation (eth0) 
starting connection 'Wired connection 1'
Mar 18 08:31:11 kolya-347 NetworkManager[813]:  (eth0): device state 
change: disconnected -> prepare (reason 'none') [30 40 0]
Mar 18 08:31:11 kolya-347 NetworkManager[813]:  Activation (eth0) 
Stage 1 of 5 (Device Prepare) scheduled...
Mar 18 08:31:11 kolya-347 kernel: [6.491855] r8169 :03:00.0 eth0: 
link up
Mar 18 08:31:11 kolya-347 kernel: [6.491872] IPv6: 
ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Mar 18 08:31:11 kolya-347 NetworkManager[813]:  Activation (eth0) 
Stage 1 of 5 (Device Prepare) started...
Mar 18 08:31:11 kolya-347 NetworkManager[813]:  Activation (eth0) 
Stage 2 of 5 (Device Configure) scheduled...
Mar 18 08:31:11 kolya-347 NetworkManager[813]:  Activation (eth0) 
Stage 1 of 5 (Device Prepare) complete.
Mar 18 08:31:11 kolya-347 NetworkManager[813]:  Activation (eth0) 
Stage 2 of 5 (Device Configure) starting...
Mar 18 08:31:11 kolya-347 NetworkManager[813]:  (eth0): device state 
change: prepare -> config (reason 'none') [40 50 0]
Mar 18 08:31:11 kolya-347 NetworkManager[813]:  Activation (eth0) 
Stage 2 of 5 (Device Configure) successful.
Mar 18 08:31:11 kolya-347 NetworkManager[813]:  Activation (eth0) 
Stage 3 of 5 (IP Configure Start) scheduled.
Mar 18 08:31:11 kolya-347 NetworkManager[813]:  Activation (eth0) 
Stage 2 of 5 (Device Configure) complete.
Mar 18 08:31:11 kolya-347 NetworkManager[813]:  Activation (eth0) 
Stage 3 of 5 (IP Configure Start) started...
Mar 18 08:31:11 kolya-347 NetworkManager[813]:  (eth0): device state 
change: config -> ip-config (reason 'none') [50 70 0]
Mar 18 08:31:11 kolya-347 NetworkManager[813]:  Activation (eth0) 
Beginning DHCPv4 transaction (timeout in 45 seconds)
Mar 18 08:31:11 kolya-347 NetworkManager[813]:  Activation (eth0) 
Beginning IP6 addrconf.
Mar 18 08:31:11 kolya-347 NetworkManager[813]:  Activation (eth0) 
Stage 3 of 5 (IP Configure Start) complete.
Mar 18 08:31:11 kolya-347 NetworkManager[813]:  (eth0): DHCPv4 state 
changed nbi -> preinit
Mar 18 08:31:11 kolya-347 dhclient: Listening on LPF/eth0/fc:aa:14:96:a0:d2
Mar 18 08:31:11 kolya-347 dhclient: Sending on   LPF/eth0/fc:aa:14:96:a0:d2
Mar 18 08:31:11 kolya-347 dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 
port 67 interval 3 (xid=0xb5185e3a)
Mar 18 08:31:12 kolya-347 avahi-daemon[808]: Joining mDNS multicast group on 
interface eth0.IPv6 with address fe80::feaa:14ff:fe96:a0d2.
Mar 18 08:31:12 kolya-347 avahi-daemon[808]: New relevant interface 
eth0.IPv6 for mDNS.
Mar 18 08:31:12 kolya-347 avahi-daemon[808]: Registering new address record 
for fe80::feaa:14ff:fe96:a0d2 on eth0.*.
Mar 18 08:31:14 kolya-347 dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 
port 67 interval 3

Re: непонятка с сетью

2016-03-19 Пенетрантность Andrei Lomov 
Tim Sattarov wrote:

> Привет,
> 
> сорри за топ квотинг.
> 
> 
> для отладки состояния сети попробуй проанализировать вывод команд:
> 
> mii-tool eth0

eth0: negotiated 100baseTx-FD flow-control, link ok


> ip link show eth0
2: eth0:  mtu 1500 qdisc pfifo_fast state 
UP mode DEFAULT group default qlen 1000
link/ether fc:aa:14:96:a0:d2 brd ff:ff:ff:ff:ff:ff

 
> ip ro

пустой вывод


> dmesg

[1.417475] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
[1.417487] r8169 :03:00.0: can't disable ASPM; OS doesn't have ASPM 
control

[1.423889] r8169 :03:00.0 eth0: RTL8168g/8111g at 
0xc9c5e000, fc:aa:14:96:a0:d2, XID 0c000800 IRQ 29
[1.423893] r8169 :03:00.0 eth0: jumbo features [frames: 9200 bytes, 
tx checksumming: ko]


[4.798686] r8169 :03:00.0 eth0: link down
[4.798706] r8169 :03:00.0 eth0: link down
[4.798724] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[5.459816] init: plymouth-upstart-bridge main process ended, respawning
[5.464461] init: plymouth-upstart-bridge main process (1185) terminated 
with status 1
[5.464483] init: plymouth-upstart-bridge main process ended, respawning
[6.491855] r8169 :03:00.0 eth0: link up
[6.491872] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready


[   66.886335] NETDEV WATCHDOG: eth0 (r8169): transmit queue 0 timed out

[   66.886338] Modules linked in: ... r8169 ahci pata_atiixp libahci mii

[   66.900726] r8169 :03:00.0 eth0: link up
[  126.925979] r8169 :03:00.0 eth0: link up


Все вроде гладко? ...

> ping 192.168.1.13
connect: Network is unreachable
 
> ip neigh
пустой вывод

Дело идет к тому, чтобы поставить нормальный debian ...


--
А.

Re: postgrey и sender verification

2016-03-19 Пенетрантность Андрей Любимец 
18.03.2016 11:14, Victor Wagner пишет:
> 
> Коллеги,
> 
> Столкнулся вот с такой проблемой - стоит у меня в postfix-е
> greylisting (postgrey). И потребовалось отправить письмо в домен,
> администратор которого настроил себе зачем-то sender address
> verification.
> 
> То есть я туда шлю письмо, а он в ответ делает smtp-коннект ко мне и,
> естественно, получает "
> 
> 
> Mar 17 18:05:58 deneb postfix/smtpd[3149]: NOQUEUE: reject: RCPT from
> .xxx.ru[nnn.nnn.nn.nn]: 450 4.2.0 :
> Recipient address rejected: Greylisted, see
> http://postgrey.schweikert.ch/help/wagner.pp.ru.html;
> from=
> 
> В результате я от него получаю 
> 450 4.1.7 : Sender address rejected: unverified
> address
> 
> И в таком состоянии оно стояло до тех пор, пока я руками не
> завайтлистил в postgrey их smtp-сервер. После этого еще через некоторое
> время (похоже там заметный таймаут на устаревание кэша unverified
> адресов) письмо всё-таки ушло.
> 
> Вопрос в том - а существует ли какой-нибудь способ сконфигурировать
> postgrey так, чтобы он отличал sender address verification от спама и
> не грейлистил её?

Надо сконфигурить postgrey, что бы он грейлистил после data, а не после rcpt to.

Re: непонятка с сетью

2016-03-19 Пенетрантность Eugene Berdnikov 
On Fri, Mar 18, 2016 at 01:46:54PM -0400, Tim Sattarov wrote:
> 
> On 18/03/16 06:43 AM, Andrei Lomov wrote:
> >> ip ro
> > пустой вывод
> >
> А адрес вообще присвоен ?
> 
> ip ad show dev eth0

 Не присвоен: из присланного лога NM видно, что на все попытки получить
 адрес по dhcp остаются без ответа, хотя линк якобы в состоянии UP.

 Я бы для начала проверил tcpdump'ом, приходят ли запросы dhcp на
 другой конец сетевого шнурка (подключив напрямую ноут, например).
 Гигабитные чипы Риалтека вроде поддерживают mdi-x, так что даже
 кросс-кабель искать необязательно, но лучше всё-таки проверить,
 что при прямом соединении линк встал в состояние up.

 Скорее всего запросы приходить не будут, а будет увеличиваться
 счётчик tx:dropped. Тогда можно попробовать выгрузить модуль
 (modprobe -r r8169), загрузить обратно с "debug=16" и прислать
 сюда то, что высыпалось в ядерный лог.
-- 
 Eugene Berdnikov

Re: postgrey и sender verification

2016-03-19 Пенетрантность Victor Wagner 
On Fri, 18 Mar 2016 10:57:38 +0500
Дмитрий Подковыркин  wrote:

> А запрос от него к вам как выглядит?

Запроса полностью в логах я, естественно, не увидел. Что в логах было -
привел (выкинув домен и IP отправителя).

Далее, остается только догадываться по логике описания процедуры Sender
verification, что оно приходит и говорит

MAIL from: double-bou...@domain.ru
RCPT to: vi...@wagner.pp.ru

На этом этапе получает 450, после этого отшибает мое письмо тоже с 450.
А потом при нескольких повторных попытках моего сервера отправить
письмо, не делает повторных попыток верифицировать адрес.

То есть картина выглядела так:
17:51 - первая попытка их доставить мне письмо. Greylisted
17:56 - вторая попытка. Письмо прошло
18:06 - я на письмо ответил. Пришел sender verification и загрейлистился
18:15 - вторая попытка доставить мое письмо. Status: Deferred без
повторной попытки верифицирвать адрес
18:25  - третья
18:45 
19:25
20:35 - продолжаем долбиться с увеличивающимися интервалами и получать
Sender rejected: unverified address
20:41 - я запустил postqueue -f вручную
20:43 - я, видя что письмо не уходит, внес их MX в whitelist
20:45 - еще одна попытка доставить письмо
21:55 - наконец случилась еще одна попытка с их стророны верифицировать
адрес. И прошла, потому что whitelisted. Может быть прошла бы и
так, на основании triplet found. Тем не менее в логе появляется еще один
их отлуп "unverified address'
23:05 - письмо наконец ушло.

Интересно, насколько распространена такая практика, и что с ней делать,
чтобы письмо не уходило по 5 часов?


> > Вопрос в том - а существует ли какой-нибудь способ сконфигурировать
> > postgrey так, чтобы он отличал sender address verification от спама
> > и не грейлистил её?

Re: wheezy iceweasel

2016-03-19 Пенетрантность Vasiliy P. Melnik 
нет - где-то читал что дальше будет фаерфокс

18 марта 2016 г., 18:18 пользователь Ivan Petrov  написал:

> Перестал работать:
> deb http://mozilla.debian.net/ wheezy-backports iceweasel-release
>
> Поддержка преращена?
>
> И
>
>

Re: непонятка с сетью

2016-03-19 Пенетрантность Maxim Nikulin 

15.03.2016 22:36, Федот Куракин пишет:

15.03.2016 17:57, Maxim Nikulin пишет:

15.03.2016 20:40, Andrei Lomov пишет:


сети нет, но вроде должна быть?:

03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c)


Видел что-то подобное с похожей картой в ноутбуке, но до конца не
разобрался. Сложилось ощущение, что слишком сильно старалась беречь
энергию. Если из suspend ноутбук выходил на аккумуляторе, то сеть не
работала, если был подключен блок питания, то обычно сеть поднималась
без проблем. Попытки выгрузить/загрузить модуль если и приводили к
успеху, то не часто.


После виндоуса надо полностью отключать питание компа (выдёргивать шнур
из блока питания).


Только вот у меня нет windows, чтобы после него что-то выдергивать.

Когда регулярно пользовался на ноутбуке ethernet, то сеть почти всегда 
работала, поэтому серьезно и не разбирался, что именно не так. Когда 
сеть вдруг совсем не поднималась, оказывалось, что хочется что-то 
сделать срочно, поэтому после пары-тройки попыток привести в чувство, 
быстрее было перезагрузить компьютер.


Иногда казалось, что несколько повышает стабильность замена network 
manager на

allow-hotplug eth0
iface eth0 inet dhcp
в /etc/network/interfaces
Временами помогало ifdown eth0; ifup eth0, до такого передергивания 
dhclient слал запросы как будто мимо кабеля.


У меня могло быть разное поведение, если компьютер загрузился с 
подключенным ethernet кабелем, если его включили с отключенным кабелем, 
но воткнули ethernet сразу после загрузки linux и если минут 10 
проработал без кабеля.


Network manager и всякие avahi-autoipd конечно могут быть излишне 
самостоятельны, но у меня было подозрение на недоделанный драйвер или 
даже кривоватую прошивку карточки.


У меня карточка чуть-чуть другая, есть дополнительно
Capabilities: [178] L1 PM Substates

Стало любопытно, есть ли какая-то польза от
Capabilities: [100] Advanced Error Reporting

Последнее время эта сетевая карточка не особенно актуально, но все равно 
интересно, в чем проблема.

[DONE] wml://{security/2016/dsa-3518.wml}

2016-03-19 Пенетрантность Lev Lamberov 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

- --- english/security/2016/dsa-3518.wml2016-03-16 21:39:34.0 
+0500
+++ russian/security/2016/dsa-3518.wml  2016-03-16 21:43:06.614978265 +0500
@@ -1,32 +1,33 @@
- -security update
+#use wml::debian::translation-check translation="1.1" maintainer="Lev Lamberov"
+обновление 
безопасности
 
- -Several vulnerabilities were found in SPIP, a website engine for
- -publishing, resulting in code injection.
+В SPIP, движке веб-сайта для издательской 
деятельности, было обнаружено
+несколько уязвимостей, которые приводить 
к инъекции кода.
 
 
 
 https://security-tracker.debian.org/tracker/CVE-2016-3153;>CVE-2016-3153
 
- -g0uZ et sambecks, from team root-me, discovered that arbitrary PHP
- -code could be injected when adding content.
+g0uZ и sambecks из команды root-me обнаружили, 
что при добавлении содержимого
+можно ввести произвольный код на языке 
PHP.
 
 https://security-tracker.debian.org/tracker/CVE-2016-3154;>CVE-2016-3154
 
- -Gilles Vincent discovered that deserializing untrusted content
- -could result in arbitrary objects injection.
+Жиль Винсен обнаружил, что 
десериализация недоверенного содержимого 
может
+приводить к инъекции произвольных 
объектов.
 
 
 
- -For the oldstable distribution (wheezy), these problems have been fixed
- -in version 2.1.17-1+deb7u5.
+В предыдущем стабильном выпуске (wheezy) эти 
проблемы были исправлены
+в версии 2.1.17-1+deb7u5.
 
- -For the stable distribution (jessie), these problems have been fixed in
- -version 3.0.17-2+deb8u2.
+В стабильном выпуске (jessie) эти проблемы 
были исправлены в
+версии 3.0.17-2+deb8u2.
 
- -For the testing (stretch) and unstable (sid) distributions, these
- -problems have been fixed in version 3.0.22-1.
+В тестируемом (stretch) и нестабильном (sid) 
выпусках эти
+проблемы были исправлены в версии 3.0.22-1.
 
- -We recommend that you upgrade your spip packages.
+Рекомендуется обновить пакеты spip.
 
 
 # do not modify the following line
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJW6Y08AAoJEF7nbuICFtKl8O0QAINbHyHwhoRRp+4Da7oSrN3D
CfQY5sJ7+xpmWPTABzh97s1SZtV7qXDjuQdluPKZIvwWvn9flxgps/jqNQPEAIfu
0VtCZMvpsYjwzwmG7+DRVgpGcuVoZnWAhY82Zz7asDvPY31YdjpAEe9VAlgp1aPc
piucUkkSvNdkx2u8MjLYkAUxr1c41UML1g6PMIwxVkVB7iXreID8RVyJJwElY1HL
1mke+xYi3EzyAmouv2H51I2ypB2XXiXak/wHrGPNuFYFD4aJBUppjgKV+ez9CfZ3
Z3DOTgAqN337xex5apkBjyBnUkpdPwi/ePjczJXOgtmd14gT/FFko15fU7Jamwek
h76NtHqY0jITx5wD1AQuhAbKi717qu7LFTjMNxfXlv1Rm+bJ4XGdbqUZrD4RKyNM
quE8HJhNMlVYlKG31nwYHTHD86dp30vWb8+uXsdyn1xH5uZBfEehezXiTWrZWQti
2pKZVG1EOXQtQNYG5RWFLasVusaAUSmF5JMdPH8i2OaY1dqNwxNI6+Al532lSKo0
BvfR2j50yH4Z0V3hrPusWtiBWvPzchT8w/0+Hwq+ZkNTnd2PKVyjLRkzDmGDKG0o
+ohsVKzZAyIzORnafycFrvUO6vCjOZcG64fQ3UGuXB9Su0QETuROgPxl/9J7aFc4
ZWiYbZTYfGV8WAcClb1Y
=2LAi
-END PGP SIGNATURE-

Re: непонятка с сетью

2016-03-19 Пенетрантность Tim Sattarov 

On 18/03/16 06:43 AM, Andrei Lomov wrote:
>> ip ro
> пустой вывод
>
А адрес вообще присвоен ?

ip ad show dev eth0

>
>
>
> [   66.886335] NETDEV WATCHDOG: eth0 (r8169): transmit queue 0 timed out
>
> [   66.886338] Modules linked in: ... r8169 ahci pata_atiixp libahci mii
>
> [   66.900726] r8169 :03:00.0 eth0: link up
> [  126.925979] r8169 :03:00.0 eth0: link up
>
>
> Все вроде гладко? ...

transmit queue 0 timed out ?

>
>> ping 192.168.1.13
> connect: Network is unreachable
>  
>> ip neigh
> пустой вывод
>
Ну да, эти пустые или unreachable потому что скорее всего адреса на
интерфейсе нет.

Validation failed

2016-03-19 Пенетрантность Debian Webmaster 
*** Errors validating /srv/www.debian.org/www/intro/organization.ru.html:
***
Line 321, character 27:  character "@" not allowed in attribute
specification list
Line 321, character 27:  element "PRESS" undefined
Line 321, character 43:  end tag for "PRESS" omitted, but its declaration
does not permit this

--
 You received this mail for the language code ru.
 Please edit webwml/english/devel/website/validation.data if this is not 
accurate
 Please also update webwml/english/devel/website/ with the new coordinator(s) 
data

[DONE] wml://{security/2016/dsa-3521.wml}

2016-03-19 Пенетрантность Lev Lamberov 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

- --- english/security/2016/dsa-3521.wml2016-03-19 20:14:26.0 
+0500
+++ russian/security/2016/dsa-3521.wml  2016-03-19 22:06:17.477391254 +0500
@@ -1,21 +1,22 @@
- -security update
+#use wml::debian::translation-check translation="1.1" maintainer="Lev Lamberov"
+обновление 
безопасности
 
- -Lael Cellier discovered two buffer overflow vulnerabilities in git, a
- -fast, scalable, distributed revision control system, which could be
- -exploited for remote execution of arbitrary code.
+Лаэль Селье обнаружил два переполнения 
буфера в git, быстрой
+масштабируемой распределённой системе 
управления версиями, которые могут
+использоваться для удалённого выполнения 
произвольного кода.
 
- -For the oldstable distribution (wheezy), these problems have been fixed
- -in version 1:1.7.10.4-1+wheezy3.
+В предыдущем стабильном выпуске (wheezy) эти 
проблемы были исправлены
+в версии 1:1.7.10.4-1+wheezy3.
 
- -For the stable distribution (jessie), these problems have been fixed in
- -version 1:2.1.4-2.1+deb8u2.
+В стабильном выпуске (jessie) эти проблемы 
были исправлены в
+версии 1:2.1.4-2.1+deb8u2.
 
- -For the unstable distribution (sid), these problems have been fixed in
- -version 1:2.8.0~rc3-1. 
+В нестабильном выпуске (sid) эти проблемы 
были исправлены в
+версии 1:2.8.0~rc3-1.
 https://security-tracker.debian.org/tracker/CVE-2016-2315;>CVE-2016-2315
- -was already fixed in version 1:2.7.0-1.
+уже была исправлена в версии 1:2.7.0-1.
 
- -We recommend that you upgrade your git packages.
+Рекомендуется обновить пакеты git.
 
 
 # do not modify the following line
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJW7YcpAAoJEF7nbuICFtKlcacQAIw7wHKlMtkRehvQl4nsmmn8
No6XoKu9lqTnJ+0MEhUCqs0oZKycl2eb7pt2hScK5rAGu3HzKHhUpiRDAmn9yHHb
0Ncr7khtZobAEFz93E2xWjNva7UstmYH5I7uj/Uj2+IPu6VddghksRCiYOqt1cnh
inByeIrOm8QWGorpJddkgzz6IwKAG7leZ0fw8h0SRDboi3OO57MRisXxgcDg9Uv5
I8SahXcqfnyO4MzLN1kaL7Ha6dbMo5k5NTN61LaPEyJDGiKF4Ord3Tc3HDAJfO40
DM6Drc19BIN+E2A5T46V3RSFI8rkOR2b/7IWHjruYrFWD5RXxAFoH7mP/1+vO2Q/
sfMMoxSzAXpbpac4HfIMS6IKOcS+NbJC+1ZUF5khSV+sToyrmMNz3pVelEm6udV0
f9lLekqre5H2Ra7ydGoeqgodWlkVzVmyEAI0T7uYvd6h/D0t3ODdVrKjIFI7uNmw
8R36glsDL1PhGO51q5Q0+L/H/2eim8pF2a3Cup9h/Dyt31fr+B6plJpnczmAprFh
a0Ym55E6+uDASdw8bmLLOZ8LQ5JDSkFOYwr7uUuxYSUyqFOXXuBTtzToUkNNAVLU
Ec9nwc5kAVbV1SxYPIisGG6lcLJsG9TS/NZxv97wDFDsZfXlrkn6Yo3HACknepph
Wk7gaJxT3hhPnKA3YlFa
=TTUZ
-END PGP SIGNATURE-

Tidy validation failed

2016-03-19 Пенетрантность Debian Webmaster 
*** /srv/www.debian.org/www/international/l10n/po/pl.ru.html
line 780 column 317 - Warning: replacing invalid numeric character reference 130

--
 You received this mail for the language code ru.
 Please edit webwml/english/devel/website/validation.data if this is not 
accurate.
 Please also update webwml/english/devel/website/ with the new coordinator(s) 
data.

Re: непонятка с сетью

2016-03-19 Пенетрантность Vasiliy P. Melnik 
Да снести его вообще, если им не пользутесь

18 марта 2016 г., 14:16 пользователь Илья  написал:

> В Fri, 18 Mar 2016 16:51:20 +0600
> Andrei Lomov  пишет:
>
> > Andrei Lomov wrote:
> >
> > > Прошу помощи.
> > > Есть роутер, к нему подключаю проводком нетбук с кубунтой
> > > 14.04, сеть работает (dhcp).
> >
> > Вот еще syslog.
> >
> > NetworkManager что-то мутит, сходу не могу понять, удалить
> > его что-ли совсем:
> >
> В /etc/NetworkManager/NetworkManager.conf есть строка?
>
> [ifupdown]
> managed=false
>
>

Re: postgrey и sender verification

2016-03-19 Пенетрантность Victor Wagner 
On Fri, 18 Mar 2016 10:33:44 +0200
"Vasiliy P. Melnik"  wrote:

> К сожалению не знаю как в постфиксе, у меня экзим, но верифай это
> отдельная процедура, и у меня в экзиме она расположена должна быть
> просто раньше грейлистинга

Тут верифай - у них, а грейлистинг - у меня.

Re: postgrey и sender verification

2016-03-19 Пенетрантность Дмитрий Подковыркин 

А запрос от него к вам как выглядит?

Вообще, по хорошему, его сервер в ответ на статус 450 должен подождать и 
проверить адрес снова через некоторое время так как 450 совсем не значит 
отсутствие адресата.


Если посмотреть в белый список portgrey, то мы там увидим только "не 
повторяет отправку" или подобные комментарии к доменам. Но нет внесения 
в белый список по причине sender address verification.



18.03.2016 10:14, Victor Wagner пишет:

Коллеги,

Столкнулся вот с такой проблемой - стоит у меня в postfix-е
greylisting (postgrey). И потребовалось отправить письмо в домен,
администратор которого настроил себе зачем-то sender address
verification.

То есть я туда шлю письмо, а он в ответ делает smtp-коннект ко мне и,
естественно, получает "


Mar 17 18:05:58 deneb postfix/smtpd[3149]: NOQUEUE: reject: RCPT from
.xxx.ru[nnn.nnn.nn.nn]: 450 4.2.0 :
Recipient address rejected: Greylisted, see
http://postgrey.schweikert.ch/help/wagner.pp.ru.html;
from=

В результате я от него получаю
450 4.1.7 : Sender address rejected: unverified
address

И в таком состоянии оно стояло до тех пор, пока я руками не
завайтлистил в postgrey их smtp-сервер. После этого еще через некоторое
время (похоже там заметный таймаут на устаревание кэша unverified
адресов) письмо всё-таки ушло.

Вопрос в том - а существует ли какой-нибудь способ сконфигурировать
postgrey так, чтобы он отличал sender address verification от спама и
не грейлистил её?




--
Подковыркин Дмитрий
ООО "Строительная компания ТРОН"
mobile:  +7 922 20 56 756
email: d.podkovyr...@comtron.ru
email: d...@ddipp.net

Re: wheezy iceweasel

2016-03-19 Пенетрантность Ivan Petrov 

Сорри, это только в wheezy или во всем дебьяне?

18.03.2016 22:24, Vasiliy P. Melnik пишет:

тю - так там так и написано : ставить фаерфокс

18 марта 2016 г., 18:18 пользователь Ivan Petrov > написал:

Перестал работать:
deb http://mozilla.debian.net/ wheezy-backports iceweasel-release

Поддержка преращена?

И

Re: postgrey и sender verification

2016-03-19 Пенетрантность Victor Wagner 
On Fri, 18 Mar 2016 11:55:19 +0300
Artem Chuprina  wrote:

> Vasiliy P. Melnik -> Victor Wagner  @ Fri, 18 Mar 2016 10:33:44 +0200:
> 
>  VPM> К сожалению не знаю как в постфиксе, у меня экзим, но верифай
>  VPM> это отдельная процедура, и у меня в экзиме она расположена
>  VPM> должна быть просто раньше грейлистинга  
> 
> Так верифай на одном конце, а грейлистинг на другом :)
> 
> Но вообще мне казалось, что sender verify должен производиться от
> имени <> (в смысле mail from: <>).  А не от какого попало.

А вот оказывается, нынче это не так: 


By default, Postfix probe messages have a sender address 
"double-bounce@$myorigin" (with Postfix versions before 2.5, the default is 
"postmaster@$myorigin"). This is SAFE because the Postfix SMTP server does not 
reject mail for this address.

You can change the probe sender address into the null address 
("address_verify_sender ="). This is UNSAFE because address probes will fail 
with mis-configured sites that reject MAIL FROM: <>, while probes from 
"double-bounce@$myorigin" would succeed.

The downside of using a non-empty sender address is that the address may end op 
on spammer mailing lists. Although Postfix always discards mail to the 
double-bounce address, this still results in wasted network bandwidth and 
server capacity. To defeat address harvesting, Postfix 2.9 and later support 
time-dependent sender addresses when you specify a non-zero 
address_verify_sender_ttl value.



http://www.postfix.org/ADDRESS_VERIFICATION_README.html

>

Re: wheezy iceweasel

2016-03-19 Пенетрантность Vasiliy P. Melnik 
а я не знаю - помню что где-то новость читал, что изначально iceweasel =
фаерфокс плюс дебиановские патчи, но патчи типа настолько классные, а мы
такие лохи, что теряем рекламу по торговой марке, а злостные дебианы ставят
в поисковик ненавистный гугль, а мы с этого не имеем ничего от яндекса, а
хотим иметь - что мы готовы признать ваши патчи лучше чем наши.

Это между строк такое читалось :)

18 марта 2016 г., 18:36 пользователь Ivan Petrov  написал:

> Сорри, это только в wheezy или во всем дебьяне?
>
> 18.03.2016 22:24, Vasiliy P. Melnik пишет:
>
>> тю - так там так и написано : ставить фаерфокс
>>
>> 18 марта 2016 г., 18:18 пользователь Ivan Petrov > > написал:
>>
>> Перестал работать:
>> deb http://mozilla.debian.net/ wheezy-backports iceweasel-release
>>
>> Поддержка преращена?
>>
>> И
>>
>>
>>
>
>

Tidy validation failed

2016-03-19 Пенетрантность Debian Webmaster 
*** /srv/www.debian.org/www/international/l10n/po/pl.ru.html
line 781 column 317 - Warning: replacing invalid numeric character reference 130

--
 You received this mail for the language code ru.
 Please edit webwml/english/devel/website/validation.data if this is not 
accurate.
 Please also update webwml/english/devel/website/ with the new coordinator(s) 
data.

Re: postgrey и sender verification

2016-03-19 Пенетрантность sergio 
On 18/03/16 08:14, Victor Wagner wrote:

> Столкнулся вот с такой проблемой - стоит у меня в postfix-е
> greylisting (postgrey). И потребовалось отправить письмо в домен,
> администратор которого настроил себе зачем-то sender address
> verification.

Почему "зачем-то"?


> Вопрос в том - а существует ли какой-нибудь способ сконфигурировать
> postgrey так, чтобы он отличал sender address verification от спама и
> не грейлистил её?

По моему нет.

Это, конечно, ни о чём не говорит, но на MX lists.debian.org graylist
c sender address verification.  У меня sender address
verification без грейлиста.  Письма от дебиана приходят исправно.


Я бы разобрался почему оно висит. 450 ведь. И на очередной попытке
отправить адрес получателя должен загрейтлиститься и sender address
verification пройдёт.


-- 
sergio

Re: непонятка с сетью

2016-03-19 Пенетрантность Artem Chuprina 
Andrei Lomov -> debian-russian@lists.debian.org  @ Fri, 18 Mar 2016 16:43:48 
+0600:

 >> dmesg

 AL> [1.417475] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
 AL> [1.417487] r8169 :03:00.0: can't disable ASPM; OS doesn't have 
ASPM 
 AL> control

 AL> [1.423889] r8169 :03:00.0 eth0: RTL8168g/8111g at 
 AL> 0xc9c5e000, fc:aa:14:96:a0:d2, XID 0c000800 IRQ 29
 AL> [1.423893] r8169 :03:00.0 eth0: jumbo features [frames: 9200 
bytes, 
 AL> tx checksumming: ko]

Чисто из разряда "еще и тут проверить".  Я натыкался на ситуацию, когда
jumbo frames, включенные на одном конце, но выключенные (за неимением,
сколь я помню), на другом, приводили к неработоспособности линка.
Симптомов не помню, увы.  Попробуй выключить.

Автоматика этого определения порой глючит.  Подозреваю, что там эмпирика...

postgrey и sender verification

2016-03-19 Пенетрантность Victor Wagner 

Коллеги,

Столкнулся вот с такой проблемой - стоит у меня в postfix-е
greylisting (postgrey). И потребовалось отправить письмо в домен,
администратор которого настроил себе зачем-то sender address
verification.

То есть я туда шлю письмо, а он в ответ делает smtp-коннект ко мне и,
естественно, получает "


Mar 17 18:05:58 deneb postfix/smtpd[3149]: NOQUEUE: reject: RCPT from
.xxx.ru[nnn.nnn.nn.nn]: 450 4.2.0 :
Recipient address rejected: Greylisted, see
http://postgrey.schweikert.ch/help/wagner.pp.ru.html;
from=

В результате я от него получаю 
450 4.1.7 : Sender address rejected: unverified
address

И в таком состоянии оно стояло до тех пор, пока я руками не
завайтлистил в postgrey их smtp-сервер. После этого еще через некоторое
время (похоже там заметный таймаут на устаревание кэша unverified
адресов) письмо всё-таки ушло.

Вопрос в том - а существует ли какой-нибудь способ сконфигурировать
postgrey так, чтобы он отличал sender address verification от спама и
не грейлистил её?


-- 
   Victor Wagner

Re: непонятка с сетью

2016-03-19 Пенетрантность Илья 
В Fri, 18 Mar 2016 16:51:20 +0600
Andrei Lomov  пишет:

> Andrei Lomov wrote:
> 
> > Прошу помощи.
> > Есть роутер, к нему подключаю проводком нетбук с кубунтой
> > 14.04, сеть работает (dhcp).
> 
> Вот еще syslog.
> 
> NetworkManager что-то мутит, сходу не могу понять, удалить
> его что-ли совсем:
> 
В /etc/NetworkManager/NetworkManager.conf есть строка?

[ifupdown]
managed=false

[DONE] wml://{security/2016/dsa-3520.wml}

2016-03-19 Пенетрантность Lev Lamberov 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

- --- english/security/2016/dsa-3520.wml2016-03-19 11:56:35.0 
+0500
+++ russian/security/2016/dsa-3520.wml  2016-03-19 11:59:17.525554762 +0500
@@ -1,20 +1,21 @@
- -security update
+#use wml::debian::translation-check translation="1.1" maintainer="Lev Lamberov"
+обновление 
безопасности
 
- -Multiple security issues have been found in Icedove, Debian's version of
- -the Mozilla Thunderbird mail client: Multiple memory safety errors,
- -integer overflows, buffer overflows and other implementation errors may
- -lead to the execution of arbitrary code or denial of service.
+В Icedove, версии почтового клиента Mozilla 
Thunderbird для Debian,
+были обнаружены многочисленные проблемы 
безопасности: многочисленные ошибки 
целостности
+содержимого памяти, переполнения целых 
чисел, переполнения буферов и другие 
ошибки реализации
+могут приводить к выполнению 
произвольного кода или отказу в 
обслуживании.
 
- -For the oldstable distribution (wheezy), these problems have been fixed
- -in version 38.7.0-1~deb7u1.
+В предыдущем стабильном выпуске (wheezy) эти 
проблемы были исправлены
+в версии 38.7.0-1~deb7u1.
 
- -For the stable distribution (jessie), these problems have been fixed in
- -version 38.7.0-1~deb8u1.
+В стабильном выпуске (jessie) эти проблемы 
были исправлены в
+версии 38.7.0-1~deb8u1.
 
- -For the unstable distribution (sid), these problems have been fixed in
- -version 38.7.0-1.
+В нестабильном выпуске (sid) эти проблемы 
были исправлены в
+версии 38.7.0-1.
 
- -We recommend that you upgrade your icedove packages.
+Рекомендуется обновить пакеты icedove.
 
 
 # do not modify the following line
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJW7PjjAAoJEF7nbuICFtKluM8QAJ2J1FXQ7K4F9KKrTeUT6y2f
zi5Ooq99VvApnaZG6mvw6AsEL9ygTjhUNR0LuF6JxOGpQyaRCHicx8K0UUC02blI
34Ki6VTJLEBJf9Z9PoLfRiZ2eCqseebkgnlBqLIt9WnAKGzezRveBisfGxzLt7O1
hfW050UcFvk6tfVcMobGroMzc49MjcreUYjCMdMZfmY9rcDYvPOKJxYbfYWQGzJ3
OegwXLCj+2V4NNc1Gp+kVJ9yIPaJn8QxW4ohs+/MXdQ/PuBK2YSggGkOJzu//YTG
+7sqhZo09t7Ez3dbkT1G9aX7ReY1hvsIiimdEkkZKHT0Evx+1M6hwPz2Zd6QBmjZ
mzCdAiG8f/jTCWKQuJN1UUYIU8342T4vybb4qxkbD7QbwSpvVkDaIdHbc613rly7
OKf8zL0sM5JFfSWaRz8dRX7JobGCSgAZZOG4qPKFVvcWE7ralfy1es11z7tvHnXn
QWAK18WqlwDCWShjrA+zNNioHCOqb7JOtOZJgi1Y0sf/XzRJR3+UUxRCuKPyUZY2
D2qPVkz62aojCGR7T5QtDrNu/yGgZcDgFQBtrzWQkrFAFdNPXwAEFW8bi1H2wv3n
eSOi+90aHDLYHyCbsLzPgmlRkBMDpnS5okJ6HroVPfq4bn+p9wN+kKwrvywRazS4
TW1lBOoH0Jz75owopVUK
=T8QH
-END PGP SIGNATURE-