Многие системные администраторы, задумываясь о безопасности данных своей компании и, в частности, о безопасности базы данных 1С, пренебрегают простым, но эффективным решением – изолировать сервер от пользователей. В данной статье проанализированы угрозы безопасности, возникающие при размещении клиентской части 1С и серверов 1С в одном сегменте сети, и рассмотрен процесс перевода серверной части 1С в другой сегмент сети. Данная статья не содержит принципиально новых решений, но может служить справочным пособием, которое объединяет информацию из различных источников.

            Если посадить тысячу мартышек за тысячу пишущих машинок, то за тысячу лет они напишут эмулятор терминала. — вместо эпиграфа.

Извините фальстарт, это не я, это андроидный смартбук.

Когда мы только запускали облако, первой проблемой было «как нам получить консоль». Штатный механизм XCP поразумевает, что консоль рисуется с помощью VNCTerm, а желающий её увидеть должен сначала пойти в XenAPI, получить там session-id консоли, пойти на порт консоли, передать session-id, получить RFB, завёрнутый в HTTP, развернуть HTTP, вынуть RFB (он же VNC), отдать её локальному рендереру VNC (VNC-клиенту или java-апплету с тем же функционалом). При этом консоль закрывалась (сессия рвалась) при каждой перезагрузке виртуальной машины. Она рвалась даже при миграции виртуальной машины. Другими словами, это была технология, которая подразумевала «глянул одним глазком, починил ssh/iptables и забыл». Неудобно, медленно, сложно. Выкатывать такое в продакт совсем не хотелось.

И я залез в дебри serial-howto, console-howto и ещё несколько ужасных документов, рассказывающих о том, как правильно нужно конфигуриовать прерывания на ISA плате у мультикарт, а так же специфику настройки linux-2.2 для работы с оными. Параллельно изучалось устройство консоли в зене (внимательный читатель мог даже заметить, когда именно я более-менее разобрался в этом вопросе — я писал на хабре краткий обзор того, что происходит с консолью).

После этого пришла мысль: нужно писать своё, потому что готового чужого хорошего нет.

Сначала мы хотели взять хотя бы готовые компоненты и сделать из них своё. Я помню до сих пор ту замечательную схему, в которой мы планировали сохранять в БД вывод anyterm'а, делать двойное туннелирование последовательного порта с использованием UDP… Выглядело это, мягко скажем, неприглядно.

Потом пришла в голову мысль выпилить anyterm. Для этого нужно было посмотреть, как работают терминалки. Это было очень забавно и поучительно (желающие могут изучить исходный текст PuTTY). Главной проблемой в этом изучении было то, что они много рисуют на экран. Прямо в процессе обработки ввода. Отделить специфику DC от, собственно, того, что является консолью, было сложно.

Через некоторое время мы пришли к идее «нам нужен свой эмулятор терминала».
Задача казалась относительно простой, пока мы не прикоснулись к бездне, именуемой «escape-коды и типы терминалов...».

Пишущие машинки

Итак, в начале была пишущая машинка. В какой-то момент возникло желание совместить телеграф с пишущей машинкой. Так возник телетайп
Разумеется, инженерам, создававшим телетайп, не было никакого резона делать все с нуля. Они просто приделали коды к каждой клавише пишущей машинки. После некоторых боёв в стиле MS VS Netscape, был создан стандарт html5 на коды для оных машинок, то бишь телетайпов. Если мне память не изменяет, то это ASCII, где предусмотрены все комбинации клавиш, характерные для американской пишущей машинки. Включая код BELL, который, кстати, должен вовсе не делать BEEP, а делать «дзыньк», ибо у пишущих машинок был именно колокольчик, а не спикер.

Одно время приходилось постоянно работать с сетевыми данными и в особенности с заголовками сетевого и транспортного уровней модели OSI. Постоянно напрягал тот факт, что многие поля были в Big-Endian, а код выполнялся на архитектуре Little-Endian. Ну невозможно было постоянно вызывать ntohl(), htonl(), ntohs(), htons()...


Автор фото: Ciroduran, источник фото: flickr.

У нас на работе как-то был довольно жаркий спор о том, считать ли python 2.7 стабильным. Итоги спора и сам вопрос я оставляю в стороне, а тут я хочу изложить и систематизировать определённые мысли о реальных программах, которые сильно противоречат миру Фон Неймана и Тьюринга.

Мир, в котором работают программисты — это мир правильного кода. Разумеется, в нём есть бесчисленные ошибки, но эти ошибки подлежат исправлению. Если это ошибки в чужом коде, который не исправить, они подлежат документированию и учитыванию в своём коде. Но ошибка — это всегда повод её найти и устранить.

Мир же системного администрирования другой. Тут код, который «какой есть, такой есть». Невозможно даже мельком прочитать исходные тексты всех пакетов даже для самой маленькой и скромной установки. 300+ Мб линукса, исходные коды основных библиотек и программ… Оно в принципе необозримо. Можно знать конкретные программы, конкретные места программ — но невозможно знать весь runtime, всё программное окружение, из которого состоит ОС.

И оно полно ошибок. Можно сколько угодно рассуждать про прелести мат. доказательств кода, но это совершенно не поможет, если сбой обнаружится в проприентарном драйвере видеокарты (казалось бы, и при чём тут сервер?) или сетевой карты с TCP offload.

К проблеме ПО есть совсем другой подход — подход сугубо практический. У нас есть априори багованный код, который иногда работает как мы ожидаем этого.

И вот вокруг этого «иногда» и строится вся концепция «стабильности» и product-ready.

Вступление

Как и было обещано в предыдущей статье, сегодня мы поговорим о базовой настройке хост-машины для работы KVM.

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

Первая часть: http://habrahabr.ru/blogs/sql/119317/

Введение

Добрый день.
Использую, как и многие, крупный торрент-трекер — rutracker.org, однако есть одна особенность которая меня раздражает.
Это добавление в список трекеров адреса ix*.rutracker.net, который служит для непонятных мне целей. Однако который часто (у меня — практически всегда) выдаёт ошибки (502 Bad Gateway и 0 No Response). Торрент-клиент (у меня Transmission) помечает торрент сломанным. Что само собой довольно сильно мне мешает. Особенно если учесть особенность Transmission — она задаёт статус торрента по последнему ответу трекера. То есть опрашиваем ix*, он возвращает ошибку, торрент помечается как Broken, через n минут/секунд опрашивается следующий трекер из списка — bt*.rutracker.org или retracker.local, которые возвращают успешный код и торрент снова становится нормальным. Такая чехарда не особо меня радует.

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

Данная статья повествует о небольшом проекте бесплатной Wi-Fi сети, об основных технических проблемах и решениях. Цель – просто рассказать о достаточно оригинальном проекте.

Чуть меньше года назад, моё руководство решило на территории организации развернуть сеть бесплатного Wi-Fi для посетителей. Все было бы просто и прозаично, если бы не одно интересное условие: прежде чем пользователь попадет в Интернет, он должен посмотреть информационную страницу, с нашей «рекламой».

После небольшого анализа пришли к выводу, что подобное можно реализовать только с помощью отдельного сервера- шлюза, скорее всего на Linux-е. Краткое ТЗ с общим описанием задачи разосланное по компаниям, занимающимся разработкой/внедрением решений хотя бы приближенных к подобному, показало, что при заказе внешнего решения стоимость проекта взлетит за облака.

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

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

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

Первая часть тут.

Здоровья всем читателям!

Вашему вниманию предлагается описание системных вызовов микроядерной операционной системы Хамелеон aka Xameleon. Мой хамелеончик ещё не вылупился из своего яйца и пока набирается сил в виртуальной машине. Но ему очень одиноко и маленькая ящерица желает поближе познакомиться с жителями Хабра.

Спор «микроядро vs монолит» ведётся много лет, но представляют ли обе спорящие стороны об архитектуре системы, построенной на микроядре? Возможно, этот топик немного прольёт свет на архитектуру микроядерных систем.

Копирайт и т.н. «правообладатели» — предмет бесконечного холивара, в т.ч. на Хабре. Авторы и правообладатели твердят, что из-за «любителей халявы» они разоряются и помирают с голоду. В нижеприведённой статье я попытаюсь показать, что индустрия умирает исключительно вследствие неспособности авторов договориться.

Представьте, что появился сервис, который за 200 рублей в месяц предоставляет полный и неограниченный доступ ко всей закопирайченной музыке, фильмам и играм. Вы согласны оплачивать такой доступ?

«Не треснет ли у тебя рожа, милейший?!» — наверняка подумал ты, %username%, читая предыдущий абзац. Не, не треснет, отвечаю я.

В комментариях к статье «Критерии качества сигнала в сетях WiMax» zlyoha посетовал на отсутствие статей описывающей физическую сторону передачи информации по радио каналу.
Мы решили исправить это упущение и написать цикл постов о беспроводной передаче данных.
В первом из них мы расскажем о главном аспекте передачи информации посредством радиосигнала – модуляции.

Внезапно обнаружил, что amarao решил сделать серию статей о том, Как стать системным администратором. Но прежде чем решаться «стать» им, стоит выяснить, кто же это такой, и что он должен делать.

В UNIX системах есть одна очень древняя команда, которая называется dd. Она предназначена для того, чтобы что-то куда-то копировать побайтово. На первый взгляд — ничего выдающегося, но если рассмотреть все возможности этого универсального инструмента, то можно выполнять довольно сложные операции без привлечения дополнительного ПО, например: выполнять резервную копию MBR, создавать дампы данных с различных накопителей, зеркалировать носители информации, восстанавливать из резервной копии данные на носители и многое другое, а, при совмещении возможностей dd и поддержке криптографических алгоритмов ядра Linux, можно даже создавать зашифрованные файлы, содержащие в себе целую файловую систему.
Опять же, в заметке я опишу самые часто используемые примеры использования команды, которые очень облегчают работу в UNIX системах.

14 апреля в вики Creative Commons опубликован перевод на русский язык «инструмента» (это не лицензия!) «CC0» (см. краткое описание на русском, см. юридический текст на английском) с помощью которого можно отказаться от своих авторских прав и передать произведение в общественное достояние.

«CC0» был запущен в декабре 2007 года. Раньше вместо «CC0» был простой отказ от авторских прав, но он был создан для работы только по законам США, в то время как «CC0» создан, чтобы работать во всём мире.

Инструмент «CC0» подходит и для контента (текста, звуков, видео, изображений), и для программного обеспечения (Фонд свободного ПО недавно включил «CC0» в свой список свободных лицензий, «CC0» как общественное достояние совместим с лицензией GNU GPL).

«CC0» работает следующим образом: автор отказывается от прав в максимально возможной по закону степени, но в том случае, если это невозможно, то предусмотрена подстраховка — тогда «CC0» превращается в простую публичную лицензию, разрешающую любое использование контента.

«CC0» работает не только для авторских, но и для смежных прав и для прав составителей базы данных, т.е. «CC0» является универсальным инструментом.

Во многих источниках упоминается, что программирование — это творчество. Другие же сравнивают его со строительством. А третьи с выращиванием сада. Но в общем сходятся во мнении, что это больше похоже на искусство. А как известно, важнейшим из искусств для нас является — кино.
Задумывались ли вы о том, насколько похожи процессы искусства кино и искусства разработки ПО (раз уж мы относим себя к творческим людям)? В обоих этих случаях результатом является произведение искусства… либо гадость, которой конечный потребитель останется не удовлетворен. Для еще большего понимания сравнения сделаем несколько шагов от фильма до приложения.
Первый шаг. Ближайший родственник фильма — мультфильм, анимация. Но по большому счету, большинство современных фильмов являются по своей сути мультфильмами.
Следующий шаг. Мультфильмы (особенно современные) безумно похожи на видео-игры. Им недостает интерактивности от поведения зрителя. В свою очередь, современные игры лишь чуть-чуть уступают качеству картинки мультфильмам и даже фильмам.
И вот мы уже в разработке игр, от которых рукой подать до производства прикладных программных систем. Цели разные, а вот процесс и подход к разработке одинаков.
Предлагаю взглянуть на процесс разработки ПО, через призму кинопроизводства. Быть может кто-то просто потешит себя сравнением и этой аллегорией, а кто-то начнет больше понимать и ценить свою роль в этом процессе.
(Скажу сразу — не снимал и не снимался в кино, но участвовал и участвую в разработке. Это фантазия — не судите строго.)
Итак, с чего начинается кино?

Так получилось, что эту весну я провёл в поисках/собеседованиях людей аж на четыре вакансии, связанные с системным администрированием. Я пообщался с несколькими десятками людей и заметил характерные ошибки и проблемы, с которыми они сталкиваются. Излагаю то, что заметил, а так же свои мысли, как эти проблемы решить.

scope: начинающие системные администраторы, помощники системных администраторов и т.д. Опытным администраторам, а так же тем, кто имеет вполне конкретную специализацию будет если и интересно, то бесполезно.

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

Какие бывают системные администраторы?

С выходом Ubuntu 11.04 оболочка Unity достаточно неожиданно заняла место оболочки по умолчанию. Появление Unity в Ubuntu Netbook Edition, несмотря на медленную скорость работы, было довольно обоснованным: оно позволило эффективно использовать маленькие экраны нетбуков, благодаря, например, вертикальной панели для переключения между запущенными программами. Почему же возникла необходимость переноса Unity на десктопы? Ответить на этот вопрос можно было бы уже сейчас. Однако такой неполный, без готовых примеров, субъективный ответ вряд ли бы удовлетворил пользователя, которому на данный момент пришлось столкнуться с неудобством перехода. Поэтому речь пойдёт о том, как улучшить, а не о том, как и зачем пережить.

Статья ориентирована на разработчиков программного обеспечения для Linux, а также для желающих начать разработку расширений для Firefox. Пользователям же предлагается пройти по ссылке за готовым расширением.

Итак, что нам понадобится: