Category: лытдыбр

Category was added automatically. Read all entries about "лытдыбр".

default

болтливое завершение фонового процесса

В "импортозамещенном" дебиане, который "Астра", при логине из /etc/profile.d/my_kewl_script.sh
запускаем фоном еще один:
another_script.sh > /dev/null 2> /dev/null &

Скрипт запускается, отрабатывает, и в момент, когда пользователь что-то вводит, его внезапно пугает строкой
[1]+ Завершен another_script.sh > /dev/null 2> /dev/null

(А пол - бетонный. В результате растет производственный травматизм.) Можно как-то убрать это сообщение? Вот даже не знаю, где искать.
screen использовать крайне нежелательно: нет в списке разрешенных.

Нет, это не первое апреля. Это я просто очень сильно туплю.

UPD: решено.
помогло добавить после запуска процесса disown another_script.sh

SATA power vs. Molex-to-SATA power

Скажите, а простой SATA power чем-то отличается от такого-же коннектора на переходнике из молекса?
Я всегда думал, что нет. Но вот сегодня взял обычный SATA диск, попытался воткнуть в свой десктоп - не заводится.
Воткнул в сервер - работает. Воткнул в USB dock - работает. Воткнул в еще 2 десктопа - не работает. Воткнул в третий, через молекс - заработал.
То есть поведение абсолютно повторяемое. Но я его понять не могу.
Может я просто чего не знаю?

P.S. диск – HGST Ultrastar DC HC510. 10TB. Ничего необычного.
  • guest_o

Локальный репозиторий CentOS

Коллеги, а внесите, пожалуйста, среди меня ясность по следующему вопросу.

Правильно ли я понимаю, что репозиторий в центоси -- это просто каталожек с RPM-пакетами и каталожек repodata, в котором лежит некоторая мета-информация о том, какие пакеты и каких версий есть в наличии? И repodata можно подготовить с помощью утили createrepo.

И потом всё это хозяйство можно просто презентовать по HTTP, прописать в yum.repos.d/myrepo.conf и дальше центось сможет беспалевно тянуть оттуда пакеты?

Вопрос вызван обилием разных каталогов различной структуры и содержания в официальных зеркалах центоси, а также необходимостью создания локальной репы (с возможностью заливания кастомных версий RPM-пакетов).

Как по фэншую вообще решается задача организации локальной репы? Можно просто отсинкать все RPM-ы откуда-нибудь (скажем, из http://mirror.centos.org/centos/7/os/x86_64/Packages/) в локальный каталог /opt/myrepo01, потом сказать creterepo /opt/myrepo01, и раздать это с http?

А как проверять актуальность/свежесть репы? Как отследить ситуацию, что в какой-то момент синк по-тихому сломался, и никаких новых версий пакетов уже не затягивается? Это как-то отражается в данных, которые генерятся с помощью createrepo? Я попробовал на одном каталоге несколько раз вызвать createrepo, без изменений в составе или версиях RPM, и оно каждый раз разные timestamp'ы в repomd.xml проставляет. Это баг или фича? Или я просто не туда смотрю?
  • guest_o

[SOLVED] Аномалии с обработкой трафика в линуксе

Приветствую.

Коллеги, требуется вмешательство коллективного разума.

Диспозиция -- есть "некий продукт", который реализует "некий функционал" (tm). По сути представляет собой готовую виртуальную машину с убунтой на борту. Функционал -- фильтрация трафика на предмет родительского контроля. Работает так -- направляем на эту виртуальную машину клиентский веб-трафик, оно заворачивает своим файрволом (iptables) себе этот трафик на определённый порт, остальное пропускает просто мимо.

Проблема такая: Если выставить вот эту убунту клиентам в качестве default gateway -- то всё работает. Если же клиентский трафик проходит предварительно через PPPoE, NAT и правило вида "pass route-to" в pf на BRASe (нам нужно не весь трафик туда заворачивать, а только от определённых клиентов), то работать перестаёт. Если снимать дамп на этом прокси, то мы видим, что пакеты до убунты доходят. Но она никак на них не реагирует:

07:51:38.157567 IP 172.20.2.2.64140 > 84.47.177.49.80: Flags [S], seq 701970860, win 65535, options [mss 1440,nop,wscale 8,nop,nop,sackOK], length 0
07:51:39.176517 IP 172.20.2.2.64140 > 84.47.177.49.80: Flags [S], seq 701970860, win 65535, options [mss 1440,nop,wscale 8,nop,nop,sackOK], length 0
07:51:41.176661 IP 172.20.2.2.64140 > 84.47.177.49.80: Flags [S], seq 701970860, win 65535, options [mss 1440,nop,nop,sackOK], length 0

Если сделать прямо на BRASe вот так:

telnet -S 172.20.2.2 84.47.177.49 80

В этом случае убунта работает как надо:

08:17:26.073705 IP 172.20.2.2.22946 > 84.47.177.49.80: Flags [S], seq 1190189962, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 2316625689 ecr 0], length 0
08:17:26.074142 IP 84.47.177.49.80 > 172.20.2.2.22946: Flags [S.], seq 1924354034, ack 1190189963, win 14600, options [mss 1460], length 0
08:17:26.074282 IP 172.20.2.2.22946 > 84.47.177.49.80: Flags [.], ack 1, win 65535, length 0
08:17:27.273320 IP 84.47.177.49.80 > 172.20.2.2.22946: Flags [S.], seq 1924354034, ack 1190189963, win 14600, options [mss 1460], length 0
08:17:27.273540 IP 172.20.2.2.22946 > 84.47.177.49.80: Flags [.], ack 1, win 65535, length 0
08:17:32.191481 IP 172.20.2.2.22946 > 84.47.177.49.80: Flags [F.], seq 1, ack 1, win 65535, length 0
08:17:32.191692 IP 84.47.177.49.80 > 172.20.2.2.22946: Flags [F.], seq 1, ack 2, win 14600, length 0
08:17:32.191940 IP 172.20.2.2.22946 > 84.47.177.49.80: Flags [.], ack 2, win 65534, length 0

Полная схема работы -- клиент подключается к BRAS'у по PPPoE, получает серый адрес из подсети 10.17.0.0/24. Пакеты от клиента натятся в белый адрес, кроме HTTP/HTTPS. HTTP/HTTPS-трафик натится в другой интерфейс в адрес 172.20.2.2, и потом ещё для этих пакетов делается правило вида route-to, чтобы для них некст-хоп был не default gateway, а IP-адрес убунты с прозрачным прокси на борту (она находится в этой же подсети -- 172.20.20.0.24. И оно не работает. Пакеты до убунты доходят, и не происходит более ничего. Скажу даже более того -- эти пакеты даже в табличке mangle файрвола не отсвечивают -- т.е. счётчик пакетов там не растёт, хотя tcpdump на убунте показывает, что они достигают нужного интерфейса. По идее, таблица mangle -- это первое, куда попадает входящий пакет, не? Я не линуксоид, просьба ногами не пинать, я просто картинку обработки трафика в линуксе посмотрел :-)

Если же клиента посадить в сеть 172.20.2.0/24 и прописать ему default gateway в виде убунты -- трафик начинает ходить.

Также если повесить на BRAS'e алиас из сети 10.17.0.0/24 и сделать:

telnet -S 10.17.0.xx 84.47.177.49 80

То тоже всё работает! Т.е. пакет, порождённый на BRAS'e и прошедший через всю схему обработки файрволом -- NAT и route-to, нормально проходит. Но пакет, пришедший через PPPoE и прошедший по той же цепочке -- уже убунтой игнорируется.

Чо за ботва?

UPD: если из схемы выкинуть PPPoE, то внезапно начинает работать. Т. е. если клиент к BRAS подключается не по PPPoe, а по чистому ethernet, то всё нормально. Если всё то же самое, с такими же IP-адресами, но клиент подключен по PPPoE -- убунта забивает на приходящие пакеты. Как так-то? С точки зрения убунты ведь в любой из ситуаций убунте приходят пакеты от имени BRAS'a (т.к. они прошли через NAT). И отличаются они только mss -- в чистом виде mss 1460, а при присутствии PPPoE mss становится меньше на 20 байт -- 1440. Больше визуально никаких отличий в трафике нет.

UPD2: Расследование показало, что когда клиент подключен по PPPoE, убунта дропает пакеты от клиента по причине invalid IP header. Сравнение пакетов в WireShark разницы между приходящими пакетами для подключенных по PPPoE и чистому ethernet не выявило. Можно как-нибудь в линухе узнать, на основании чего конкретно он посчитал IP header пакета invalid'ным?

UPD3: Разобрались. Косяк оказался в файрволе pf на BRAS'e. На брасе у нас стоит FreeBSD 9.3 с mpd 5.7 на борту в качестве PPPoE-сервера. Переброс клиентского трафика осуществлялся через NAT и правило вида pass out ... route-to (менялся next-hop для определённого набора клиентов). По какой-то причине pf в правиле route-to для пакетов, попавших на сервер через PPPoE, криво проставлял чексумму IP-заголовка -- менял там старший и младший байт местами. Т.е. если сумма должна быть 0xABCD, то на выходе после route-to в pf получалось 0xCDAB. В результате пакет на убунте дропался из-за кривой чексуммы. Починили путём переноса функционала NAT и маршрутизации на IPFW -- после него чексумма заголовка не ломается. Нашли даже похожий древний баг: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=93530

Критика хабровской статьи "Dell готовится к приходу процессоров ARM в серверы"

Читя Хабр, я наткнулся на феерически некомпетентную статью "Dell готовится к приходу процессоров ARM в серверы". Ни слова про применение ARM конкретно в серверах и конкретно фирмой DELL там нет, зато есть масса полностью неверных утверждений.

У меня нет возможности писать на Хабр, поэтому я оставляю эту критику здесь. Возможно, это научит кого-то внимательно читать статьи и не особенно доверять им.

С самой зари компьютерной эры, точнее, с появления процессоров Intel 8086, параллельно существуют две основных архитектуры – х86 и RISC.
О том, что в момент появления процессоров Intel 8086 было довольно много CISC-процессоров, автор, конечно же, не знает.

Собственно, противороставление тут вообще некорректно, т.е. "Intel 8086" - это конкретная архитектура (ну, линейка архитектур), тогда как RISC - это группа архитектур, имеющий некий общий признак (и надо заметить, что граница этой группы довольно расплывчата).

RISC-процессоры обрабатывают ограниченный набор команд, что накладывает некоторые ограничения на их применение
Интересно было бы услышать, какие именно ограничения существуют в реальности.

Вообще-то, RISC-процессоры проектируются так, чтобы быстро выполнять операции, которые нужны достаточно часто. Те операции, которые требуются редко, просто приходится выполнять несколькими командами - но т.к. это случается редко, производительность не страдает.

Но тут нужно заметить, что бывает и наоборот: некоторые команды RISC-процессоров делают то, что на CISC-процессоре требует нескольких команд.

Ключевое отличие RISC, которое трудно победить адаптацией программного кода к системе команд, – в отсутствии вычислений с плавающей точкой.
Видимо, автор ни разу не смотрел систему команд процессоров Alpha, Sparc и остальных.

Сначала в основной процессор интегрировали математический сопроцессор в поколении 386
Ну точно, автор ничего не изучал на практике, а просто читал плохие книжки, которые ещё и неправильно понял.

На процессоре 386 появились 32-битное адресное простраенство и страничная защита памяти. А математический сопроцессор был интегрирован внутрь чипа на процессоре 486.

Pentium был оснащен потоковым конвейером для обработки мультимедиа MMX
Формально с некоторой натяжкой это можно считать верным. Но фраза порождает чёткое ощущение, что автор не знает предмета, а просто комбинирует слова в синтаксически верные предложения.

А что же RISC? Чтобы не углубляться в дебри его архитектуры
А вот ещё одно чёткое доказательство ненкомпетентности автора: знающий человек написал бы не "его архитектуры", а "их архитектур"!

Процессоры ARM всегда были относительно простыми, небольшими и энергоэффективными. Использовались они для узкоспециализированных, предметно поставленных именно для них задач.
Я просто дам сылку и две картинки:


Процессоры х86 изначально работали под управлением DOS и UNIX. Microsoft на смену DOS вырастила большое семейство Windows
Вообще-то, первые версии Windows (тогда ещё 16-битные) появились гораздо раньше, чем Unix был портирован на х86. Собственно, до появления 386-го процессора (см.выше) портировать Unix было не то чтобы невозможно, но нереально по трудозатратам.

И где-то рядом с ним — MacOS, работавшая в юности на RISC-процессорах.
Тут мы видим интереснейший пример фразы, которая формально верна, но вводит неквалифицированного читателя в заблеждение.

Дело в том, что MacOS начиналась на коммпьютерах с CISC-процессорами Motorola 68k. Последующие версии - на коммпьютерах с RISC-процессорами PowerPC (PPC). С середины 2000-х - на компьютерах с процессорами Intel.

Самое большое заблуждение, которое может породить эта фраза - будто MacOS, в юности работала на процессорах ARM. Именно это и следует из контекста цитируемой статьи.

ARM изначально работали под управлением собственных программ, которые в полной мере не являлись операционными системами, в привычном для всех понимании.
А как же RISC-OS???

FreeBSD, mpd и логи

"Какие красивые длинные логи..."
Поговорка


Продолжаем готовиться к стремительно наступающей пятнице. Дяденьки, вы только не бейте, я не настоящий админ, я просто в серверной консоль нашёл.

В общем, дело такое -- после ротации логов mpd5 логи вестись перестают до перезапуска демона syslog. Куда бы ему пнуть побольнее, чтобы логи не переставали вестись после ротации? Я с этой проблемой уже несколько раз пытался разбираться, но никакое курение интернетов что-то ни к чему не привело.

Там есть опция в newsyslog.conf, типа, "оповестить демон N об факте ротации логов". Я это всё пробовал делать, с таким же нулевым эффектом. А чо делать-то? Перезапускать mpd по факту ротации логов как-то криво...

Дело происходит в FreeBSD 8.1, версия mpd -- 5.5.
Op

Распаковщик/упаковщик прошивок Cisco IP Phone 79xx

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

А вот кому про прошивки IP-телефонов Cisco 79xx (CNU-based)? Пару лет назад я писал в ru_voip или в ru_embedded о том, что я написал распаковщик-упаковщик прошивок для этих телефонов, речь шла про 7941/7961 и аналоги. Но тогда выложить исходники мне было стыдно, так как их требовалось хоть чуть-чуть привести в порядок.  Руки дошли до этого только после того, как я уволился с работы :). Ну и плюс я немножко поковырял эти прошивки уже сейчас.  Правда, самого телефона у меня уже нет, но  предыдущие исследования и то, что удалось понять из прошивки, я выложил в виде небольших статей на сайт.

Поле для экспериментов там непаханное, имея голову и руки, а в руках кросс-компилятор, можно принести много-много радости людям. Так что у кого есть такие телефоны, понимание того зачем это все надо и нужный скилл - карты в руки, что называется. Буду рад если кому-то материал окажется полезным - знания должны работать, а не в столе лежать. Сейчас ru_voip подохло практически, поэтому я решил запостить сюда тоже.

Поскольку в свете недавних постов слово "новогодний подарок" уже вызывает некоторое раздражение, я просто дам ссылки на свой сайт, который, собственно, появился ради документирования этого проекта и какой-никакой практики в переводе на английский (смеятса уже можно, да).

Сам распаковщик: http://virtualab.ru/projects/cnu-fpu
Все материалы (статьи, about+формат прошивки и т. д.): http://virtualab.ru/category/projects/cnu-fpu
kalian

FreeBSD и битые сетевые карты?

Странный случай произошел с фришкой 4.11. Новый комп, поставили 2 обычные интеловские карточки fxp, налили фришку с рабочей машинки дамп-ресторе, грузится, линк поднимает, пинги не ходят. Запускаем tcpdump/trafshow - пинги начинают ходить. Пока идея, что карточка отдает в сеть MAC не тот, которым себя считает. tcpdump переводит ее в promiscuous mode и она ловит уже и "свои" пакеты тоже.

Самое странное в этом, что интегрированная карта на реалтеке ведет себя так же. Вставили 3com - вроде поехало все.

ifconfig fxp0 inet ... ether xx:xx... не додумались сразу проверить, надо было срочно, да и ставить кривоватую машинку не хочется, не бог весть какая у нее задача, но все-таки нужно: поставил и забыл на год.

Это мне повезло с партией кривых китайских интел-карт? А что еще можно попробовать, кроме софтварной смены МАКа?
  • Current Mood
    sexy