Re: iceweasel
On Tue, Sep 29, 2015 at 10:57:24PM +0600, Ivan Petrov wrote: > И еще теперь iceweasel в упор не видит многие ttf шрифты, например, times > > Откуда он берет шрифты? /usr/share ? Зависит: libfontconfig1 также как и большинство приложений fc-list и т. д.
Re: Странное поведение TCP
On 2015-09-29, Max Dmitrichenko wrote: >> Если я правильно понял эту фразу, от сервера после RST идёт ожидаемый >> ответ приложения. Это свидетельствует о том, что RST посылает не ядро >> сервера, а некая посторонняя программа, прослушивающая трафик где-то >> между клиентом и сервером. > > Приходит не ответ приложения, а просто TCP-шный ACK, на посланные > клиентом данные. Причем у него TTL тоже 125. Версия с вражеской > железкой на пути меня давно посетила. Просто не понятно, для чего > такая железка может применятся. Работал я в одном банке программистом с обязанностями поддержки сопровождаемых комплексов. Когда постили тикет во внутреннем Redmine со словом SELECT (пользователь вставил содерж. диагностич. сообщения) - запрос не доходил до сервера. Девопсы никак не смогли помочь, сетевики в силу забюрократизированости недоступны рядовому разрабу. В общем мы перевели сервис на HTTPS )) Далее была машинка, с которой иногда были RST, как у вас, но без какой либо явной связи. И мучились мы пол года, девопсы полчали, достукавшись до сетевиков - крестились что ничего нету, в общем раскидав красивые скриншоты от wireshark со стрелочками и пояснениями бяки по "менедженту" нам в итоге сказали что было установлены железки от DDos защиты (для внутрикорпоративного трафика cis!). Спустя пару дней хост згорел, сервисы перенесли на другой хост в другой сети и проблемы исчезли. В обоих случаях пакостили безопасники, обладая большими полномочиями ни перед кем не отчитываются + топология сети держится в секрете, в таких условиях нет полной картины развертывания ПО и разбираться можно долго. -- Best regards!
Re: Странное поведение TCP
Max Dmitrichenko wrote: > 29 сентября 2015 г., 10:17 пользователь Eugene Berdnikov > написал: > >^M > > На дамп можно глянуть? Лучше всего в формате pcap. > Протокол прориетарный, я его не знаю. Там скорее всего передаётся > авторизация. На сколько она криптована, хз, но скорее всего by > obscurity. Но сервер более-менее публичный. Поэтому утечку допустить > не хотелось бы. Так запиши дамп без пайлоада. Нужны то только L2+L3 хидера.
Re: iceweasel
И еще теперь iceweasel в упор не видит многие ttf шрифты, например, times Откуда он берет шрифты? /usr/share ? 29.09.2015 22:44, Eugene Berdnikov пишет: On Tue, Sep 29, 2015 at 10:34:26PM +0600, Ivan Petrov wrote: Нашел Файл в ~.mozilla/firefox/название профиля/places.sqlite. Если его снести, шрифты начинают настраиваться. Что за файл? История посещений, букмарки, etc... sqlite3 places.sqlite sqlite> .schema Дальше, если немного знаете SQL, можете рассматривать таблички. Что там может влиять на шрифты -- не знаю.
Re: iceweasel
Нашел Файл в ~.mozilla/firefox/название профиля/places.sqlite. Если его снести, шрифты начинают настраиваться. Что за файл? 29.09.2015 00:07, Melleus пишет: Ivan Petrov writes: 28.09.2015 20:06, Илья пишет: lxappearance - > Font - > Antialising ? >> Сглаживание полное включено. Проблема в том, что iceweasel 40.1 перестал реагировать на настройки шрифтов On 09/26/2015 04:24 PM, Ivan Petrov wrote: Обновил squeeze + lxde поставился новый iceweasel Слетели шрифты и в самом iceweasel отказываются настраиваться. Все интернет страницы показываются каким-то шрифтом без засечек с очень плохим сглаживанием. Это где-то в openbox настраивается? И. man fonts.conf может?
Re: iceweasel
On Tue, Sep 29, 2015 at 10:34:26PM +0600, Ivan Petrov wrote: > Нашел Файл в ~.mozilla/firefox/название профиля/places.sqlite. > Если его снести, шрифты начинают настраиваться. > Что за файл? История посещений, букмарки, etc... sqlite3 places.sqlite sqlite> .schema Дальше, если немного знаете SQL, можете рассматривать таблички. Что там может влиять на шрифты -- не знаю. -- Eugene Berdnikov
Re: Стабильная система?
А насчет стабильности стейбла - так вот сегодня с удивлением заметил, что еще и Clementine больше не проигрывает ape-файлы. Когда отвалилось - не отследил, но на предыдущем стейбле все прекрасно воспроизводилось. Ну, а у меня Plymouth давно отъехал. В Wheezy всё работало. А сейчас, дескать, не хотим, чтобы ты NVIDIA драйвера проприетарные из репозитория использовал, если хочешь смотреть картинку при загрузке. Ну, может танцами с бубном и возможно завести и на проприетарных драйверах. Но с введением systemd стабильность упала, я принимаю это, как неизбежное зло. Да и то, что где-то что-то у кого-то еще хуже - это весьма слабое оправдание. Всегда можно найти кого-нибудь, у кого хуже дела идут. Но проблема в том, что не найдёте лучше. Лично мне болезнь понятна - она связана с экстравагантными инновациями одного из разработчиков, чересчур известному чтобы называть его имя. Угу. И сообщество вместо того, чтобы заниматься действительно актуальными вещами вынуждено тратить свое драгоценное время и ресурсы на то, чтобы хоть как-то сгладить косяки лезущие из всех щелей его псевдо инноваций. Все проходит. И это пройдет тоже. Но потеряны годы. Админы говорят, что им давно такого не хватало. В Редмонде рады, конечно. Вряд ли: они свой дистрибутив Linux пилят.
Re: Стабильная система?
On 28.09.2015 23:34, Artem Chuprina wrote: Артём Н. -> debian-russian@lists.debian.org @ Mon, 28 Sep 2015 10:37:48 +0300: АН> Offtopic: АН> А что кто-то реально использует Haskell? Да. И на данный момент я его считаю лучшим вариантом по соотношению затрат на разработку и уверенности в результате, с БОЛЬШИМ отрывом от конкурентов. А, если не секрет, для разработки чего и, что важно, кем, а также для кого?
Re: Что-то непонятное с автомонтированием NTFS
Да видел я разницу. Монтировал с теми же опциями. Всё работало. У меня подозрение на двойное монтирование. On 28.09.2015 16:46, Tim Sattarov wrote: On 2015-09-28 04:51, "Артём Н." wrote: При включении USB HDD автоматиччески монтируется NTFS раздел: /dev/sde3 on /media/windows_part type fuseblk (rw,nodev,noexec,noatime,user_id=0,group_id=0,,allow_other,blksize=4096) [skip] При ручном перемонтировании всё работает: # mount /dev/sde3 /media/windows_part && ll -d /media/windows_part && mount |grep sde3 drwxrwxrwx 1 root root 16K сен 25 10:36 /media/windows_part /dev/sde3 on /media/windows_part type fuseblk (rw,relatime,user_id=0,group_id=0,allow_other,blksize=4096) Пока не приходит в голову откуда у проблемы ноги растут. Подскажите. 1) Посмотреть вывод dmesg (journalctl -k ) 2) скорее всего дело в опциях монтирования (см разницу в своем выводе) если устраивает отсутствие nodev,noexec,noatime,default_permissions то изменить настройки автомонтирования, убрав эти опции.
Re: Стабильная система?
Алексей Витальевич Коротков -> debian-russian@lists.debian.org @ Tue, 29 Sep 2015 11:16:10 +0400: AC>> А вот поиск по именам пакетов из индекса с выводом описаний - это AC>> лишнее в этом инструменте, на мой взгляд. АВК> Я бы предпочёл иметь хоть такой, чем ничего. AC>> Наверное, лучше было бы иметь AC>> отдельный инструмент, который искал бы более продвинуто, и которому AC>> можно было бы показать индекс. АВК> Согласен. И я вот задумался... Локальный hoogle, часом, не справится ли, имея только индекс? Хотя, наверное, вряд ли, он искалка по API, а API в индексе нет.
Re: Странное поведение TCP
On Tue, Sep 29, 2015 at 12:09:21PM +0300, Max Dmitrichenko wrote: > 29 сентября 2015 г., 11:08 пользователь Eugene Berdnikov > написал: > > Поскольку "чёрный ящик", в нём может жить некая сущность, рвущая > > коннекции по своему усмотрению. Типичные гадости такого рода делаются > > железками от Cisco, с их бредовыми inspect'ами и rate limit'ами. > > Опознаётся подлянка по id'ам, ttl'ам и прочим деталям, отличающим > > посторонние RST от тех, которые генерит ядро сервера. > > Да, TTL действительно отличается. У SYN-ACK и других пакетов он 125, а > у этого RST - 254. Вот и ответ. Вероятно, это циска, она рвёт коннекции пакетами с ttl=255. То есть между ней и тем местом, где снимался дамп, ровно один роутер. А сервер, подозреваю, под Windows, между ним и вредителем ещё 1 роутер. -- Eugene Berdnikov
Re: Странное поведение TCP
29 сентября 2015 г., 11:57 пользователь Eugene Berdnikov написал: > If the incoming segment has an ACK field, the reset takes its > sequence number from the ACK field of the segment, otherwise the > reset has sequence number zero and the ACK field is set to the sum > of the sequence number and segment length of the incoming segment. > > Ref: RFC793 (этот текст встречается там в нескольких местах). На странице 37 этой RFC есть требование того, что RST должно "попадать" по sequnce. А ваша цитата похоже отностися к поведению стэка, когда ему приходит вообще левый пакет на левый порт, но с правильным IP-адресом назначения. >> При этом, что самое смешное, после RST от сервера приходит ACK на >> данные клиента. > > Если я правильно понял эту фразу, от сервера после RST идёт ожидаемый > ответ приложения. Это свидетельствует о том, что RST посылает не ядро > сервера, а некая посторонняя программа, прослушивающая трафик где-то > между клиентом и сервером. Приходит не ответ приложения, а просто TCP-шный ACK, на посланные клиентом данные. Причем у него TTL тоже 125. Версия с вражеской железкой на пути меня давно посетила. Просто не понятно, для чего такая железка может применятся. -- With best regards Max Dmitrichenko
Re: Странное поведение TCP
29 сентября 2015 г., 11:08 пользователь Eugene Berdnikov написал: > On Tue, Sep 29, 2015 at 10:57:42AM +0300, Max Dmitrichenko wrote: >> > На дамп можно глянуть? Лучше всего в формате pcap. >> >> К сожалению в силу ряда причин нет ( > > Откуда тогда такие подробные сведения о механизме сбоя? Кто-то же > должен был смотреть дамп трафика, чтобы рассуждать о SYNах, RST... У меня-то дамп есть. Просто я не уверен, что уполномочен им поделится с вами. > Поскольку "чёрный ящик", в нём может жить некая сущность, рвущая > коннекции по своему усмотрению. Типичные гадости такого рода делаются > железками от Cisco, с их бредовыми inspect'ами и rate limit'ами. > Опознаётся подлянка по id'ам, ttl'ам и прочим деталям, отличающим > посторонние RST от тех, которые генерит ядро сервера. Да, TTL действительно отличается. У SYN-ACK и других пакетов он 125, а у этого RST - 254. -- With best regards Max Dmitrichenko
Re: Странное поведение TCP
Вдогонку. On Tue, Sep 29, 2015 at 09:00:26AM +0300, Max Dmitrichenko wrote: > 3) Так вот, иногда бывает так, что сервер внезапно на первые > присланные данные отвечает RST. Причем отвечает не сразу, а через > время, которое на десятки миллисекунд превышает RTT. И всё бы хорошо, > но у данного RST-пакета SEQ=0, а после SYN-ACK, он должен быть равен > 1. Из-за этого, клиентский Linux игнорирует данный RST пакет и > продолжает думать, что соединение живо. If the incoming segment has an ACK field, the reset takes its sequence number from the ACK field of the segment, otherwise the reset has sequence number zero and the ACK field is set to the sum of the sequence number and segment length of the incoming segment. Ref: RFC793 (этот текст встречается там в нескольких местах). > При этом, что самое смешное, после RST от сервера приходит ACK на > данные клиента. Если я правильно понял эту фразу, от сервера после RST идёт ожидаемый ответ приложения. Это свидетельствует о том, что RST посылает не ядро сервера, а некая посторонняя программа, прослушивающая трафик где-то между клиентом и сервером. -- Eugene Berdnikov
Re: Странное поведение TCP
On Tue, Sep 29, 2015 at 10:57:42AM +0300, Max Dmitrichenko wrote: > > На дамп можно глянуть? Лучше всего в формате pcap. > > К сожалению в силу ряда причин нет ( Откуда тогда такие подробные сведения о механизме сбоя? Кто-то же должен был смотреть дамп трафика, чтобы рассуждать о SYNах, RST... Поскольку "чёрный ящик", в нём может жить некая сущность, рвущая коннекции по своему усмотрению. Типичные гадости такого рода делаются железками от Cisco, с их бредовыми inspect'ами и rate limit'ами. Опознаётся подлянка по id'ам, ttl'ам и прочим деталям, отличающим посторонние RST от тех, которые генерит ядро сервера. -- Eugene Berdnikov
Re: Странное поведение TCP
29 сентября 2015 г., 10:17 пользователь Eugene Berdnikov написал: > > На дамп можно глянуть? Лучше всего в формате pcap. Протокол прориетарный, я его не знаю. Там скорее всего передаётся авторизация. На сколько она криптована, хз, но скорее всего by obscurity. Но сервер более-менее публичный. Поэтому утечку допустить не хотелось бы. -- With best regards Max Dmitrichenko
Re: Странное поведение TCP
29 сентября 2015 г., 10:17 пользователь Mikhail A Antonov написал: > 29.09.2015 09:00, Max Dmitrichenko пишет: >> Добрый день, коллеги. Вопрос не совсем по Debian, но связан в >> некоторой степени с администрированием. >> >> Есть некоторый сервер, к которому выполняется TCP-подключение. >> 1) Во-время установления соединения происходит стандартный TCP-шный >> handshake (SYN, SYN-ACK, ACK). > Что за сервер? > На сколько далеко клиент и сервер? В одной локальной сети? Да в общем-то рядом. Это другой сегмент сети, но типичный RTT составляет сотни микросекунд. -- With best regards Max Dmitrichenko
Re: Странное поведение TCP
> На дамп можно глянуть? Лучше всего в формате pcap. К сожалению в силу ряда причин нет ( -- With best regards Max Dmitrichenko
Re: Помогите с bind.
29.09.2015 10:44, Pavel Volkov пишет: > On 2015年9月24日木曜日 16時31分15秒 MSK, Nikolay Shestakov wrote: >> Ну, в России лучше пользоваться DNS от Яндекса https://dns.yandex.ru/[1] > > Но там нет ни DNSSEC, ни IPv6, это несовременно :) > IPv6 нет говоришь? https://dns.yandex.ru/advanced/ -- Best regards, Mikhail - WWW: http://www.antmix.ru/ XMPP: ant...@stopicq.ru signature.asc Description: OpenPGP digital signature
Re: Странное поведение TCP
29 сентября 2015 г., 10:17 пользователь Mikhail A Antonov написал: > 29.09.2015 09:00, Max Dmitrichenko пишет: >> Добрый день, коллеги. Вопрос не совсем по Debian, но связан в >> некоторой степени с администрированием. >> >> Есть некоторый сервер, к которому выполняется TCP-подключение. >> 1) Во-время установления соединения происходит стандартный TCP-шный >> handshake (SYN, SYN-ACK, ACK). > Что за сервер? > На сколько далеко клиент и сервер? В одной локальной сети? > Есть ли NAT между ними? Вообще про сервер ничего не известно. Black box. Хотя подозреваю, что там может быть некий load balancer или какая-то железка по отражению атак. -- With best regards Max Dmitrichenko
Re: Помогите с bind.
On 2015年9月24日木曜日 16時31分15秒 MSK, Nikolay Shestakov wrote: Ну, в России лучше пользоваться DNS от Яндекса https://dns.yandex.ru/[1] Но там нет ни DNSSEC, ни IPv6, это несовременно :)
Re: Странное поведение TCP
29.09.2015 09:00, Max Dmitrichenko пишет: > Добрый день, коллеги. Вопрос не совсем по Debian, но связан в > некоторой степени с администрированием. > > Есть некоторый сервер, к которому выполняется TCP-подключение. > 1) Во-время установления соединения происходит стандартный TCP-шный > handshake (SYN, SYN-ACK, ACK). Что за сервер? На сколько далеко клиент и сервер? В одной локальной сети? Есть ли NAT между ними? -- Best regards, Mikhail - WWW: http://www.antmix.ru/ XMPP: ant...@stopicq.ru signature.asc Description: OpenPGP digital signature
Re: Странное поведение TCP
On Tue, Sep 29, 2015 at 09:00:26AM +0300, Max Dmitrichenko wrote: > 3) Так вот, иногда бывает так, что сервер внезапно на первые > присланные данные отвечает RST. Причем отвечает не сразу, а через > время, которое на десятки миллисекунд превышает RTT. И всё бы хорошо, > но у данного RST-пакета SEQ=0, а после SYN-ACK, он должен быть равен > 1. Из-за этого, клиентский Linux игнорирует данный RST пакет и > продолжает думать, что соединение живо. На дамп можно глянуть? Лучше всего в формате pcap. -- Eugene Berdnikov
Re: Стабильная система?
On Tue, 29 Sep 2015 09:19:44 +0300 Artem Chuprina wrote: AC> А вот поиск по именам пакетов из индекса с выводом описаний - это AC> лишнее в этом инструменте, на мой взгляд. Я бы предпочёл иметь хоть такой, чем ничего. AC> Наверное, лучше было бы иметь AC> отдельный инструмент, который искал бы более продвинуто, и которому AC> можно было бы показать индекс. Согласен.
