Во время затянувшегося кризиса провайдеры начинают бороться за каждого пользователя. Сделать это можно несколькими путями: либо уменьшать абонентскую плату, но тут есть определенные пределы, никто же не хочет работать себе в убыток; либо вводить новые услуги.

На настройки одной из них в сетях Ethernet-провайдера и посмотрим.

Хочу поднять вопрос, который, как мне кажется, никто не рассматривал ранее системно. Вопрос звучит так:

как называть узлы и интерфейсы узлов в сети?

Для начала обрисую суть проблемы: когда у вас 2-3-5-10 серверов, то их названия, адреса и т.д. вы быстро запоминаете, и особой путаницы они не вызывают. Но если у вас несколько тысяч серверов (добавим к реальным ещё виртуальные), если у вашего маршрутизатора несколько сотен реальных или виртуальных (в виланах) интерфейсов, каждому из которых нужно дать имя (хотя бы для PTR/A записей в DNS), когда у вас есть интерфейсы для конфигурирования коммутаторов, принт-серверов, сетевых принтеров… В этих условиях нужно реально садиться и думать, как их называть. Лучше садиться думать до того, как начали называть, чем после.

Итак, мы все знаем про подлых пользователей c UID=0 в unix, которых может быть больше одного.

Посмотрим, как такое же (а на самом деле, даже более страшное) организовывается в инфраструктуре Windows. Разумеется, мы говорить будем не про локальные виндовые учётные записи, а про Active Directory, т.е. говорить будем об администраторе домена. Или, даже, хуже, об enterprise administrator.

Итак, истина номер один: у объектов в active directory есть атрибуты и права доступа.
Истина номер два: эти атрибуты можно менять.

Как легко понять, мы МОЖЕМ сделать учётную запись с фантастическими правами, к которой не будет доступа НИ У КОГО. Однако, он сможет логиниться, блокировать, разблокировать, менять свои атрибуты и атрибуты чужих людей.

В самом страшном случае, это будет пользователь с волшебным SID-*500, которого не позволяет удалить уже сама винда. (Для этого нужно переименовать, а на его место положить другого пользователя с ником Administrator и с полными правами).

Под катом описано как шейпировать трафик в Linux и что для этого нужно знать.

Ни для кого не секрет, что в Unix системах вся информация предоставляется в виде файлов.
В Linux есть файл /proc/kcore, который является «алиасом» на физическую память системы.
Мануалы говорят, что полная длина этого файла — это размер физической памяти (RAM) плюс 4KB, но повертев этот файл на разных системах я пришел к выводу, что размер файла равен размеру RAM + SWAP.
Аналогично этому файлу можно использовать устройства /dev/mem или /dev/kmem, но взаимодействие с ними в данном топике я не буду рассматривать.

Дело было вечером, делать было нечего… Дернуло меня поглядеть на QtScript, на котором пишутся плагины для Амарока, ну, думаю, просто смотреть неинтересно — надо чего-то написать. Ну, а так как я в это время слушал музыку именно из Контакта, так как не для кого не секрет, что там можно найти практически все, то было решено заменить совсем неудобный плеер контакта на Амарок, дабы была возможность нормально этим делом управлять посредством мультимедийныйх клавиш и да и просто для объединения в один плейлист композиций локальных и сетевых.

С радостью для себя обнаружил на Хабре некоторое количество статей на тему весьма мне близкую — IPTV.
Решил внести свой небольшой вклад написанием этой статьи.

Небольшое введение

Один интернет провайдер центрального региона имеет в коммерческой эксплуатации в нескольких городах услугу IPTV. Одной из основ, точнее, самой главной основой является наполнение этой услуги контентом, это очевидно. И разумеется, оператору гораздо удобнее агрегировать весь контент в одном месте, откуда, используя свои межрегиональные сети передачи данных, вещать его в филиалы.

Постановка задачи

Оператор в месте агрегации контента имеет:
1. Серверную ферму предоставления услуги IPTV;
2. Стык фермы с региональной сетью филиала;
3. Стык фермы с МСПД (межрегиональная сеть передачи данных);
4. МСПД от региональной сети на серверной ферме отделена с использованием VRF.
Необходимо на одном из серверов фермы шифровать мультикаст и передавать его в таком виде в МСПД и региональную сеть, не используя никаких дополнительных устройств видеомультиплексирования. Сервер шифрования выступает здесь в качестве стримера, на который наложены определенные ограничения:
1. Один телеканал — одна лицензия, одна мультикастовая группа.
2. Стримить сервер может только с одного интерфейса (один адрес источника мультикаста — это основная проблема).
ОС сервера шифрования — RHEL5.4, сетевое оборудование фермы — Cisco серии 7600.

Доброго времени суток.
Хочу вам рассказать про настройку приема спутниковых не закодированных тв каналов в linux и вещание их в локальную сеть.
Исходными данными будем считать наличие спутниковой антенны настроенной на определенный градус(например на www.lyngsat.com/amos2.html) и компьютера под управлением linux(не важно какой дистрибутив, в моем случае был Slackware). Задача очень интересная и актуальная в наше время.

Один очень близкий мне человек, поклонник Хабра, захотел внести вклад в развитие блога Cisco. Являясь яростным поклонником того, что создает эта корпорация, он захотел поделиться опытом. =) Надеемся росчерк пера удался.

Относительно недавно мне посчастливилось познакомить и даже поконфигурять multicast routing для IPTV. Изначально, я с этой темой была совершенно не знакома, и это заставило меня вылакать горлышко от цистерны водки перекопать огромное количество документации, чтобы войти в курс дела.

И вот незадача. Обычно в документации выкладывают все и сразу и для человека, впервые столкнувшегося с этой темой, не понятно с чего начать. Во время чтения pdf’ок я ловила себя на мысли, что было бы неплохо наткнуться где-нибудь на статью, которая могла бы коротким путем провести от теории к практике, чтобы понять с чего стоит начать и где заострить внимание.

Мне не удалось обнаружить такую статью. Это побудило меня написать эту статейку для тех, кто также как и я столкнется с вопросом, что это за зверь IPTV и как с ним бороться.