Слайды.

Слайды.

Презентация.

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

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

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

Смотрите в полноэкранном режиме.

Стоит отметить то, что исполняемый код сайта (PHP) на целевом сервере работает по схема схема nginx—php-fpm, а выбор файла — через try_files. Так же подчеркиваю, что требуется проверка, является ли пользователь разработчиком. Эти два фактора вместе отметали простые классические решения этой проблемы (в Гугле их масса, например).

Самое простое решение без проверки (разработчик или нет) заключается в том, что  бы проверять наличие специального файла в начале до проверки других условий. Это можно сделать с помощью try_files, подставив файл страницы с ошибкой первым в очереди. Но помимо того неудобства, что требуется добавлять/удалять файл в исходниках сайта (что не очень хорошо при заливке исходников через системы контроля версий), этот вариант просто не работает в сочетании с секциями if, которые появятся для добавления проверки «разработчик или нет». После входа в любую секцию if try_files ведет себя своеобразно и неправильно резолвит полные пути к файлам; источник проблемы описан тут.

Кстати, а по какому признаку мы будем проверять, является ли пользователь разработчиком? Ну, вариантов достаточно много. Самый удобный и популярный вариант — по наличию «специальной» cookie. Еще один популярный вариант — по IP. На какой фактор полагаться, большой разницы нет. В любом случае требуется проверка значения некоторой переменной, и осуществить эту проверку можно только с помощью секции if.

Резюмируя описанное выше: мы не можем делать проверку на наличие файла страницы обслуживания вместе с проверкой дополнительного фактора «разработчик или нет», используя try_files. Значит, проверку на наличие файла можно делать только с помощью if. В nginx if не может принимать два условия. Но эта проблема решается. Казалось бы, что цель достигнута. Проверяем 2 фактора: наличие файла и факт того, что пользователь — разработчик. Но такие проверки обязательно требуют входа хотя бы в один if. И тут опять фэйл: после входа в любой if try_files ведет себя своеобразно и неправильно резолвит полные пути к файлам после входа в секцию if; источник проблемы описан тут.

Короче, все довольно запутано и мутно. После нескольких часов мучительного подбора вариантов решение таки было найдено. Я выбрал способ проверки разработчика по cookie. Схема вышла очень простой. Один из if-ов был заменен map-ом, который работает нормально с try_files. А объединение условий (наличия файла и cookie) было реализовано через подмену пути к этому файлу. Т.е. в случае, когда пользователь — разработчик, мы просто портим имя файла, наличие которого свидетельствует о включенном режиме обслуживания.

Итоговая конфигурация.

В секции http (вне секций server) прописываем проверку «разработчик или нет». Она будет распространяться на все сайты в случае виртуального хостинга. В данном случае, если у пользователя установлена cookie DEVELOPER_SECRET_COOKIE со значением 1100110101, то пользователь будет признан разработчиком.

map $http_cookie $isDevHack {
    default "";
    ~DEVELOPER_SECRET_COOKIE=1100110101 "/non-existed-location";
}

В соответствующей секции server объявляем собственный обработчик ошибки 503, которая будет использована для индикации режима обслуживания:

error_page 503 @maintenance;
location @maintenance {
    rewrite ^(.*)$ /maintenance-mode.html break;
}

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

Теперь осталось определить, нужно ли показывать страницу «на обслуживании». В секциях location, для которых должно работать это правило, в начале (до применения других правил, которые работают в нормальном режиме работы сайта) добавляем:

if (-f "$isDevHack/home/site_root/maintenance") {
    return 503;
}

В данном конкретном случае проверяется наличие файла в домашнем каталоге сайта. Вообще, проверять файл можно где-угодно. Проверка будет работать только для обычных пользователей, потому что переменная $isDevHack из нашего map-а выше испортит это имя в случае, если пользователь — разработчик, так что файл никогда не будет найден.

Пример конфига nginx целиком для сайта example.com.

Самая известная в определенных кругах версия Internet Explorer 6 вышла в августе 2001 года перед выпуском Windows XP. Она стала эпохальной. Дальнейшая активная разработка браузера фактически прекратилась.

Только в 2006 вышла версия Internet Explorer 7 для Vista, которая наконец-то включила в себя то, что давно стало стандартом во всех современных браузерах — вкладки. Кроме того, были исправлены многие ошибки 6-й версии, добавлена поддержка некоторых новых стандартов.

За эти годы (перерыв между версиями 6 и 7) Microsoft почти потеряла рынок. Компанию не интересовали ни проблемы пользователей, ни разработчиков. Опомнились они только тогда, когда ситуация стала угрожающей. Версия Internet Explorer 8, которая уже могла хоть как-то претендовать на конкуренцию в современных условиях, вышла только в марте 2009. Пожалуй, это был ответ на выпуск Google Chrome (бета в сентябре 2008). В Microsoft вернулся интерес к рынку браузеров.

Почему же вначале 2000-х разработка Internet Explorer была заброшена? О чем думали в Microsoft, когда делали такой перерыв (5 лет!) между выпусками версий в такой конкурентной и динамичной области, как Интернет, где все меняется с огромной скоростью?

Сомнений нет — это стратегические решения. Ведь денежный вопрос в Microsoft точно не стоял. А профессиональный уровень менеджеров и руководителей компании не вызывает сомнений. Стратегия 90-х основывалась на продажах Windows и привязке разработчиков и пользователей к Windows API. Подробнее об этом написано у Джоэла Спольски. Для Веба API операционной системы не имел никакого значения. Привязки в конкретной ОС не было. Следовательно, Microsoft потеряла заинтересованность в развитии своего браузера. Ведь изначально он служил целям популяризации и привязки пользователей к Windows. А в 2000-х эффект стал обратным — Веб стал отвязывать пользователей, привязанных с таким трудом к Microsoft.

Так как ускорять такое развитие событий Microsoft было не выгодно, разработка браузера была заброшена, а инициатива — отдана конкурентам. В 2006-м Microsoft пришлось доработать свой браузер для Vista, так как версия 6 к тому времени перестала нормально решать задачу пользователя Windows — серфинг в Сети. Поэтому версия 7 не сделала больших шагов вперед, если не считать исправления ошибок.

Более важным был выход следующей версии — Internet Explorer 8 (март 2009). Microsoft сменила стратегию — браузер стал ближе к разработчикам. В последних версиях IE наблюдаются четкие попытки достичь нормального современного уровня по тем фронтам, где Explorer отстал наиболее значительно. Начались постоянные компании по продвижению IE, в том числе и среди разработчиков веб-приложений. Участился выпуск новых версий.

Что заставило Microsoft изменить стратегию и вновь взяться за развитие своего браузера? Начало новой эры развития Интернета! Я об этом писал раньше. Сейчас Google заставляет шевелиться Microsoft. На данный момент, из-за опозданий последней, Google одержал победу в битве на поле браузеров. Но война еще не окончена. И не последнее слово в ней будет за Windows 8, в состав которой войдет Internet Explorer 10.

Посмотрите на

Но самое важное то, что они намекают на скорый отказ от классических программных технологий для десктопного программирования и продвигают новые, которые раньше применялись только в Вебе — HTML и JavaScript. Это пугает всех разработчиков настольных приложений для Windows, потому что они, по сути, теряют весь наработанный опыт и становятся в положение новичков на рынке (речь как об индивидуальных разработчиках, так и об огромных компаниях).

Почему Microsoft так поступает? Пытается тягаться с Google и Facebook? Или просто в компании понимают, что уже в ближайшем будущем суть операционной системы, как и классического десктопного прикладного программного обеспечения, в корень изменится?

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

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

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

С развитием скоростного, постоянно- и повсеместно-доступного Интернета ситуация начала меняться. Стали появляться веб-сервисы, ориентированные на замену старого десктопного софта. Прямая связь между компьютером пользователя и серверами размывалась стандартными протоколами Интернета. Значительно упростились требования к пользовательскому железу. И самое главное, что выбор операционной системы перестал влиять на выбор сервисов, потому что все они работали на технологиях, которые не зависят от платформы: HTML+CSS, XML, JavaScript.

Хост приложения разделился на две слабо связанных составляющих: клиентская и серверная. Причем хостом на клиентской стороне на этот раз целиком и полностью выступал веб-браузер, а не операционная система. От характеристик последней уже практически ничего не зависело. Это развязало руки пользователям — появилась возможность выбирать. Отчасти по этой причине удалось захватить неплохой кусок рынка OS X.

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

Коренным образом изменились для разработчиков и критерии выбора операционной системы — отпала необходимость выбирать ту же ОС, что и у пользователей

Да, мы пользуемся большим количеством онлайн-сервисов, но подавляющее большинство софта по-прежнему все еще офлайн! — скажите вы, — Тогда о чем говорить: ничего не поменялось!

Нет, поменялось. Забудем пока о работе и рассмотрим досуг. Что нужно среднестатистическому пользователю домашнего ПК? Простенький текстовый редактор для написания заметок в блог. Простой табличный процессор для ведения домашней бухгалтерии или расчета стоимости покупки телевизора в кредит. Простое приложение для базового редактирования, хранения, каталогизации и просмотра фотографий и видео. Приложение для прослушивания музыки. Болталка (IM) для коммуникаций с другими людьми. И, конечно, браузер для чтения новостей. Пожалуй, все.

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

Сейчас весь перечисленный список программ доступен в Вебе бесплатно! Возможно, для русского человека выделенное курсивом слово безразлично — у него и так все бесплатно. Давайте на секунду представим, что все это надо купить. А еще надо купить операционную систему, чтобы оно работало. Возможно, покупка набора нужного ПО обойдется дороже, чем стоимость ноутбука, на котором оно будет работать. Так что выделенное курсивом слово дает возможность сэкономить раза в два.

Работая с веб-приложениями ничего не нужно устанавливать и обслуживать. «Сломалась» Winsows? Нет проблем, переустановить ее не сложно. Сложно поставить и настроить после установки еще 15 программ. С веб-сервисами это не нужно, для пользования ими достаточно даже встроенного в ОС браузера. А это дает еще один большой дополнительный бонус — мобильность.

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

Фактически, для среднестатистического пользователя больше не требуется от операционной системы ничего, кроме возможности включиться и запустить браузер, чтобы пользоваться облачными веб-приложениями. Тогда зачем ее покупать? Можно взять простую бесплатную ОС. Например, Chrome OS. Именно эту нишу спешно пытается занять Google. Linux — не конкурент для Windows на десктопах, конкурент для Windows — это Chrome OS.

Пока у Microsoft есть фора перед Google. У них есть пользователи. Один раз Google уже обыграл Microsoft на их поле — доля браузера Chrome уже больше, чем Internet Explorer. Скоро Google постарается повторить свой успех в чемпионате разработчиков операционных систем. Что особо забавно — с тем же именем — Chrome. Очевидно, что в Microsoft все это прекрасно понимают и пытаются действовать на опережение. Почитайте заметку Джоэла Спольски «Огонь и движение» — во второй половине он как раз об этом пишет.

Microsoft пытается сделать из своей операционной системы онлайн-портал. Новый плиточный интерфейс рассчитан именно на то, что все представленные на этой «доске» приложения-плитки будут выводить основную актуальную информацию, полученную из Сети. Запущенное приложение занимает весь экран и не требует вспомогательных инструментов на подобии файлового браузера или других приложений. Процесс работы с ним больше напоминает работу с сайтом, чем с классическим десктомным приложением.

Microsoft хочет сделать тоже самое, что и Google, — операционную систему-браузер — хост для веб-приложений, полностью интегрированный с Сетью. Это и есть будущее операционных систем. Никакого больше десктопного софта! Только веб-приложения, которые запускаются прямо в операционной системе (зачем лишняя прослойка в виде браузера?).

Сегодня такое будущее не представляется реальным в обозримой перспективе — снова парируете вы. Да, нужно признать, что огромное количество программных продуктов пока не готово к переходу в облака (вы можете называть «это» как хотите, но суть не изменится; мне больше нравится слово «облака», чем, например, «режим онлайн»). Но уже сегодня по всем фронтам разработки все идет именно к этому! Игры — класс самых тяжелых для переноса в Сеть приложений. Но, посмотрите — в последнее время появляется все больше серьезных браузерных онлайн-игр (например, Command & Conquer). Их качество растет. Рабочие приложения для бухгалтеров, инженеров, дизайнеров, программистов тоже начали переход— постепенно появляются онлайн-аналоги десктопного софта. 1С, Adobe и другие гиганты ставят «облачные» цели (правда, причины там другие).

Кто-то делает это потому, что модно. Кто-то — потому, что понимает все описанное выше. У других причины свои. Но в любом случае — сейчас все начинают. Полностью перейти в онлайн пока не реально, и это нормально. Вспомните, сколько времени занял переход от консольных приложений к GUI. Во многих банках до сих пор сотрудники работают в DOS, хотя уже больше 20 лет прошло. Переход в облака займет еще больше времени, потому что задача на порядок сложнее. Но рано или поздно веб-технологии достигнут нужного уровня и переход произойдет. Кто будет больше готов к нему лучше, тот и выиграет. Кто не будет готов — останется не у дел. Мы уже проходили такое в истории индустрии программного обеспечения, и будем проходить снова во время каждой очередной смены эпохи технологий.

Так каким же я вижу будущее операционных систем? Операционная система станет чем-то похожим на веб-браузер, установленный на голое железо. Современный классический интерфейс (разработанный в Xerox PARC и впервые внедренный Apple почти 30 лет назад) отойдет в прошлое. Многие современные составные части ОС станут попросту не нужны, другие скроются от пользователя и превратятся в сервисы API для программистов. Основной задачей ОС станет предоставление возможности запуска клиентской части облачных сервисов. И преимущества, которые имеет Microsoft в современном мире ОС, будет значительно растеряны. Им придется придумывать новые способы привязки к себе пользователей и программистов в новой среде, более конкурентной, по сравнению с нынешней.

Когда это произойдет? Думаю, ответить не сможет никто. Многое зависит от решений, успехов и неудач крупных софтверных компаний, таких как Microsoft, Google, Facebook. В отличие от той эволюции софта, которую мы наблюдали в девяностых и двухтысячных, новая эволюция все меньше будет зависеть от производителей железа, и все больше — от производителей конечного ПО для пользователей.

Ценность материала в том, что:

1) это хороший способ взглянуть на себя со стороны огромному числу программистов PHP, так как общая средняя квалификация этого класса программистов значительно ниже среднего по другим более серьезным языкам; взгляд со стороны поможет понять свои проблемы и найти способы их преодоления;

2) конкретные советы о том, что следует почитать/посмотреть.

Ссылка на материал: Как стать хорошим программистом и хорошим php-программистом в частности?

А ниже позволю себе сделать частичный копипаст предложенных решений.

Мастерство программирования (или скорее можно назвать Основы)

• Совершенный код,
• Чистый код,
• Рефакторинг,
• Программист-прагматик,
• Архитектура корпоративных программных приложений,
• Кодеры за работой.

Нашел очень хорошую и исчерпывающую статью на английском: How to be a Programmer: A Short, Comprehensive, and Personal Summary

Курсы, выложенные по MIT OCW:

• MIT Electrical Engineering and Computer Science

Курсы Стэнфорда:

• Mashine learning
• Natural Language Processing class
• Software Engineering for Software as a Service class

На каждом сайте внизу есть ссылки на другие курсы Стэнфорда.

Алгоритмы.

Как развивать:

Искусство программирования Кнутта — читать и выполнять задания.

Project Euer — задания по алгоритмам, можно писать на PHP.

ООП и Шаблоны проектирования

PHP: объекты, шаблоны и методики программирования М. Зандстра сейчас, наверное, лучшая книга для введения в шаблоны проектирвания для PHP.

Head First Design Patterns, на русском Паттерны проектирования — очень рекоммендуют, как очень хорошо разъясняющую книгу.

какие книги, методы обучения, задачи порекоммендуете?

PHP основы

Как развивать:

собственно работа по профессии и набор опыта,

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

Потом есть stackoverflow, там введи в поиск ~php~ и читай вопрос, давай свой ответ (про себя), потом смотри, что другие написали. Будешь по тегам смотреть заодно, что пхп-ники изучают.

Javascript Основы

Как развивать:

собственно работа по профессии и набор опыта,

JavaScript. Подробное руководство. Д. Флэнаган (читать и разбираться в пропущенных основах — типы, обьектная модель и др.)

JavaScript: The Good Parts

JavaScript. Шаблоны

Источник: Как стать хорошим программистом и хорошим php-программистом в частности? Ни автор, ни комментаторы не имеют ко мне никакого отношения.

Все предложения хостинга можно разделить на 4 группы: Shared hosting (общий сервер), VPS (virtual private server — частный виртуальный сервер), Dedicated (выделенный сервер) и Cloud (облачный хостинг). Colocation (размещение сервера) в расчет не берется, так как это просто аренда места в стойке, а не хостинг.

Итак, с чем же можно провести аналогию?

Первое, что пришло в голову — ресторан. Shared — небольшой стол, заполненный едой, а вокруг стоя тянет руки толпа студентов. VPS — типичный ресторанный стол, у каждого своя еда на тарелке, присутствует малая группа людей. Dedicated — один за столом. Cloud — вот тут самое интересное. Толком придумать идею не получилось. Если у кого получится, велкам в комменты.

Чтобы восстановить пробел с Cloud, решил перенести фокус со стола на одну емкость — стакан. Shared — стакан с жидкостью забит трубочками. VPS — стакан перегородками поделен на 4 равные части, в каждой части своя трубочка. Dedicated — одна трубочка в стакане. Cloud — система стаканов, соединенных трубочками. К этой системе равномерно подключаются трубочки «клиентов».

Всё сходится, аналогия получается хорошая. Но нормально изобразить ее графически у меня не вышло. Выкладываю то, что получилось :) Если кто-то сможет нормально нарисовать эту красоту, буду весьма признателен :)

Если я не первый, кто провел такую аналогию, было бы также интересно об этом узнать.

Решение. В консоли выполняем следующие команды:

$ sudo modprobe -r psmouse
$ sudo modprobe psmouse proto=imps

Заработал скрол? У меня — да. Если у вас тоже, по результат надо закрепить. Для этого открываем /etc/modprobe.d/options и добавляем туда строку.

sudo gedit /etc/modprobe.d/options

Строка:

options psmouse proto=imps

Теперь и после ребута скрол останется работать.

P.S. Печальные последствия такого способа заключаются в том, что из настроек мыши пропадает вкладка Touchpad.

Решение отсюда: http://superuser.com/questions/136568/get-back-the-touchpad-scrolling-missing-in-kubuntu-10-04

Если взять одного из ведущих российских облачных хостеров — selectel.ru, у которого самая низкая стоимость за Гб/час хранения данных (0,005 р), то месяц хранения бэкапов будет стоить 360—540 рублей в месяц. Это около $15. Много. При этом, платить надо еще за трафик и работу виртуальной машины во время синхронизации.

Рассмотрим сервис хранения файлов от Amazon. До терабайта там цена от $0.093 за Гб. Для хранения моих бэкапов понадобится от $9,3—14. Это поменьше, но там нет виртуальной машины, а значит сложнее синхронизация.

Для сравнения посмотрим на Dropbox. Мы знаем, что он хранит пользовательские данные на Amazon S3. Значит, не должно быть дешевле, чем в расчетах Амазона. Аккаунт Pro (100 Гб) стоит $20 в месяц. Да, дороже более чем в 2 раза.

Может Ubuntu One? 20 Гб у них стоят $3. Значит я заплачу примерно $14—22. Тоже дорого…

Стоимость внешних HDD от 250 Гб начинается от $55. Хоть надежность такого бэкапа будет гораздо ниже, чем в случае облаков, да и возни больше (ведь нельзя хранить винчестер в той же локации, где и сервер; а значит нужно либо носить его туда-сюда, либо договариваться с кем-то о бэкапах через интернет). Зато цена приятная: даже по Амазону наш HDD окупится через 6 месяцев.

Во всех расчетах не учитывались затраты на трафик. При первой синхронизации они будут велики ($10—20 для облаков), но при последующих синхронизациях они будут относительно небольшими (трудно подсчитать, ну пусть будет $1—2 в мес.). Для внешнего HDD затрат на первый слив не будет.

Есть также сервис, специализирующиеся на бэкапе в облака. Гуглятся по запросу «cloud backup». Я несколько штук посмотрел, но цен ниже $15 в месяц за 100 Гб не видел. Только больше.

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

Материал разделен на три части: А — теория, Б — практика, В — создание мультизагрузочной флэшки.

А. Общая теория (популярно).

1. Железо.

Все физические устройства, которые используются нами повседневно для хранения информации (HDD, CD-ROM, флэшка, и даже флопик) — это блочные устройства ввода/вывода (block I/O device). Они могут подключаться к компьютеру через различные интерфейсы: IDE, SATA, eSATA, USB. Операционная система предоставляет единый прозрачный для пользователя и программиста прикладного ПО способ чтения/записи информации с/на эти носители.

С железом напрямую общаются драйвера. Драйвер — это программа, загруженная в операционную систему. Он является прослойкой между ОС и устройствами, представляя для ОС стандартный программный интерфейс блочных устройств I/O.

2. Данные на физическом диске.

Блочными эти устройства называются потому, что информация на них записывается и считывается блоками (секторами, кластерами) фиксированного размера. Размер блока кратен 512 байт. Блочный подход необходим для обеспечения высокой скорости работы дисковой подсистемы.

Сам диск форматируется (размечается) на низком уровне (на заводе). Диск состоит из цилиндров. Цилиндр — это окружность на пластине диска. Первые цилиндры расположена в центре пластины диска, последние — на внешнем краю. Каждый цилиндр делиться на секторы. В пределах секторов организуются блоки на диске. Помимо самих данных в блоках записывается информация для контроля ошибок. С этой информацией работает контроллер внутри жесткого диска и она не видна снаружи. Драйвер посылает команды контроллеру диска на уровне «считать 10 блоков 10 цилиндра 20 сектора».

Все полезные данные, записанные на носитель, организованы в разделы. В Windows каждый раздел обычно представлен в виде логического диска (C, D, E, …). На сменных носителях (флэшка, компакт-диск, флопик) как правило создан один единственный раздел, на внутренних жестких дисках — наоборот — обычно несколько разделов. Данные в разделе организованы в файловой системе.

Для каждого раздела может независимо устанавливаться свой размер блока — размер кластера. Он регулирует баланс скорость/экономичность. Блок — это минимальная адресуемая единица разметки на диске. Кластер объединяет несколько блоков — это минимальная адресуемая единица в разделе.

Таким образом устанавливается следующая логическая иерархия (от внизу вверх): блок, сектор, цилиндр — кластер — раздел — файл, каталог.

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

3. Разметка физического диска.

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

Так как на диске может быть несколько разделов, их нужно где-то перечислить с указанием пределов и свойств каждого раздела. Для этого служит таблица разделов, которая находится в начале физического диска (начало диска — это его первый блок в соответствии с адресацией). В классическом случае она входит в состав MBR (master boot record), которая целиком занимает первый блок. На всю таблицу разделов выделено 64 байта. Каждая запись таблицы состоит из адресов начала и конца раздела, типа раздела, количества секторов в разделе и флага «загруженности» раздела и занимает 16 байт. Таким образом максимальное количество разделов на диске ограничено четырьмя (16 × 4 = 64).

Так сложилось исторически, но со временем стало очевидно, что 4 раздела не всегда достаточно. Решение проблемы было найдено. Те разделы, которые размечены в заголовке диска (в MBR), назвали Primary (первичные). Их по прежнему должно быть до 4-х включительно. Дополнительно ввели понятие Extended (расширенных) разделов. Расширенный раздел включает один или более подраздел и не содержит файловой системы. Сам он является полноценным первичным разделом.

Так как подразделы расширенного раздела не перечислены в таблице разделов диска, их невозможно пометить как загрузочные. Загрузочный (bootable) раздел — это тот раздел, с которого начинает загружаться операционная система. Он отмечается флагом в своей записи таблицы разделов. Таким образом отметить можно только один из 4-х первичных разделов. Расширенный раздел загрузочным быть не может, так как на нем нет файловой системы.

Разметка расширенного раздела описана в в его начале. По аналогии с MBR существует EBR (Extended boot record), расположенная в первом секторе. В ней описывается разметка логических дисков данного расширенного раздела.

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

4. Файловая система.

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

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

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

В процессе работы на диске могут возникать физические повреждения. Некоторые блоки могут становиться недоступными для чтения. Эти блоки называют «бэдами» (bad sector). Если в процессе чтения диска попадает бэд, происходит ошибка ввода/вывода (I/O error). В зависимости от того, в каком месте появился бэд-блок и сколько их появилось, может потеряеться либо часть содержимого файлов, либо в часть таблицы файлов.

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

5. Работа с диском.

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

В ОС семейства UNIX все устройства хранения данных представлены в виде файлов в каталоге /dev:

• sda, sdb, sdc, … — физические диски (HDD, включая внешние, флэшки, IDE-сидиромы);

• fd0, fd1 — флопики.

Разделы на каждом из дисков доступны в виде sda1, sda2, sd3, …

Нумерация дисков происходит в том порядке, в котором их видит BIOS. Нумерация разделов — в порядке создания разделов на диске.

Чтобы сделать образ (образ — это побитовая копия информации, размещенной на диске или в разделе) диска целиком (например первого по BIOS — sda), нужно вычитать данные из /dev/sda в любой другой специально созданный для образа файл, используя программу последовательного копирования содержимого файла. Чтобы записать образ в файл, нужно при помощи той же программы вычитать данные из образа в /dev/sda. По аналогии можно создать/восстановить образ раздела (например, первого на первом диске — sda1), обращаясь к /dev/sda1 вместо /dev/sda.

6. Монтирование.

Чтобы «превратить» дисковое устройство в набор файлов и каталогов, к которым можно получить доступ, его необходимо примонтировать. В Windows как такового монтирования не существует. Там разделы просто подключаются к логическим дискам (C:, D:, E, …). Информация о том, какую букву присвоить какому диску, хранится в самой ОС.

В UNIX понятие монтирования является основоположным в работе с дисками и дает значительно больше гибкости, чем есть в Windows. Монтирование — это процесс привязки некоторого источника образа диска (это либо сам диск, либо файл с его образом) к некоторому каталогу в файловой системе UNIX. Файловая система в UNIX начинается из одной точки — от корневого каталога (/), и никаких логических дисков C, D, E не существует.

В начале загрузки ОС семейства UNIX в корневой каталог / монтируется раздел диска, помеченный как root (корневой). На разделе диска должны быть созданы служебные каталоги ОС, находящиеся в корне файловой системы. К ним могут монтироваться другие разделы, либо файлы могут записываться прямо в основной раздел (примонтрированный к /).

Ключевой момент заключается в том, что источник образа диска (блочное устройство, файл с образом или каталог уже примонтированной файловой системы) можно монтировать к любому каталогу на любом уровне вложенности файловой системы, которая начинается с /. Таким образом, разные логические разделы физического диска представляются каталогами в единой файловой системе в противоположность отдельным файловым системам разных логических дисков в Windows (там каждый диск рассматривается как автономная файловая система, имеющая свой корень).

Для монтирования необходимо указать файловую систему образа, опции монтирования и каталог, к которому будет привязка.

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

7. MBR — загрузочная область.

В начале физического диска обычно расположена MBR (master boot record). Это загрузочная область диска. При загрузке компьютера BIOS определяет какой диск является первичным (primary) и ищет на нем MBR. Если она найдена, то ей передается управление. Если нет, выводится ошибка о том, что загрузочный диск не найден.

В MBR, кроме таблицы разделов (описано выше), располагается код программы, которая загружается в память и выполняется. Именно эта программа должна определить загрузочный раздел на диске и передать ему управление. Передача управления происходит аналогично: первый блок (512 байт) загрузочного раздела помещается в оперативную память и выполняется. Он содержит программный код, который инициирует загрузку ОС.

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

Код GRUB слишком большой, чтобы поместиться в MBR. Поэтому он устанавливается на отдельном разделе (обычно в том разделе, который монтируется в /boot) с файловой системой FAT, FFS или Ext2. В MBR записывается код, который загружает код GRUB с определенного раздела и передает ему управление.

GRUB самостоятельно или с помощью пользователя определяет с какого раздела должна происходить загрузка. В случае Winsows-раздела ему просто передается управление точно так же, как это было бы из обычной MBR. В случае Linux-а загрузчик выполняет более сложные действия. Он загружает в память ядро ОС и передает ему управление.

Сделать бэкап загрузочной области диска так же легко, как бэкап всего диска или отдельного раздела. Суть в том, что MBR занимает первые 512 байт диска /dev/sda. Следовательно, для бэкапа MBR необходимо вычитать первые 512 байт /dev/sda в файл, а для восстановления — наоборот — файл вычитать в /dev/sda.

Озадаченно смотрю на версии «свежего софта»…

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

Объясните — в чем смысл? Только в «проверенности» и стабильности этих версий?

Ответ:

Да. И это «только» весьма дорогого стоит. Более того, в рамках политики дебиана обновляться версии будут только на security fix’ы, то есть никаких новых фич до момента явного dist-upgrade’а. Сравните с убунтой, в которой каждые N дней пачка обновляемых пакетов.

Для десктопа это, может быть и нормально, но для сервера — неприемлимо. Я лично несколько раз сталкивался с дурацкими проблемами при обновлении версий (к счастью, только на декстопе). В списке лидеров — evolution (похерил архив почту), krusader (похерил половину настроек), deluge (криво подцепил старые настройки).

Если такой же сюрприз произойдёт на продакт-сервере, это будет очень не смешно. Особенно, если учесть сложность отката некоторых изменений в распределённых системах, даже при наличии бэкапа.

Таким образом, stable — это идеальное решение для сервера. А sid/ubuntu — вполне хорошо для _своего_ десктопа (решать проблемы похерившейся почты у себя неприятно, но решать их же у главбуха — куда грустнее).

Кстати, ровно той же политики придерживается и RHEL (CentOS) — у них в пятой версии до сих пор 2.6.18, хоть и с кучей бэкпортов.

© amarao, Хабрахабр.

Полностью защитить протокол общения пользователя с сервером можно только одним способом — шифрование трафика. Экзотические способы шифрования, а также создание различного вида тоннелей мы не рассматриваем. Только обычное SSL-шифрование протокола HTTP, которое поддерживает любой современный браузер — HTTPS.

Причем, работает нормально HTTPS только в том случае, если для пользователя не произошло незаметной подмены сертификата (как это делает софт на подобии SecureTower). В случае, если сертификат подменяется незаметно или пользователя в открытую заставляют принять невалидный сертификат (т.к. иначе ничего не будет вообще) HTTPS работать перестает.

И вот, учитывая это, возникает вопрос: если полностью защитить трафик мы не можем, то можем ли мы защитить хотябы самое важное? Например, пароль. В принципе, можем, но тоже не на 100%. Пароль можно хэшировать до передачи на сервер JavaScript-ом. Тогда перехватчик получить хэш. Он сможет по нему авторизоваться, но сам пароль не увидит. Правда, его можно подобрать брутфорсом. С шифрованием самого пароля (вместо хэширования) картина примерно та же, только реализация гораздо сложнее.

Давать возможность пользователю работать с сайтом по HTTPS можно, но заставлять нужно только тогда, когда шифрование реально необходимо: например, в интернет-банкинге. Дело в том, что у некоторых компаний могут быть закрыты исходящие соединения на 443-й порт, либо запрещен бинарный трафик.

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

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

Но в этом случае большинству пользователей эта защита может оказаться непонятной и ненужной. Если мы хотим им помочь, то следует определить, доступен ли клиенту HTTPS автоматически и, в зависимости от результата, установить обычную авторизацию, либо защищенную. Только пользовалею надо сообщить о том, какой способ выбран (можно графически).

Именно так поступили в Яндексе. У них я подсмотрел способ определения доступности HTTPS. Подгружается JS с https://, который устанавливает флаг в DOM-модели страницы. Форма авторизации ведет себя по разному в зависимости от этого флага.

Хэшировать ли пароль? Это может иметь значение только в одном случае: если у пользователя один пароль на несколько сервисов. Тогда перехватчик не увидит пароля в открытом виде, чтобы использовать его на других сервисах. Но подобрать брутфорсом пароль все равно возможно. Только это уже не так тривиально, как подсмотреть в открытом виде. Так что если вы на стороне пользователя, постарайтесь пароль хэшировать до передачи.

А как делают другие?

Про Яндекс я уже рассказал. Добавлю, что пароль он передает в открытом виде и не пускает на главную страницу портала по HTTPS.

Mail.ru ведет себя как Яндекс, только их способа определения поддержки HTTPS я не нашел (хотя и не глубоко искал).

Google работает по HTTPS нормально. Пароль передает в открытом виде. Авторизацию по умолчанию предлагает защищенную. Способов определения, поддерживает  ли клиент HTTPS, я не нашел.

Facebook, как и Google, прекрассно работает по HTTPS. Авторизация по умолчанию защищенная. Пароль в открытом виде.

Вконтакте, Одноклассники, TUT.BY и Onliner.by по HTTPS не отвечают, защищенную авторизацию не предлагают, пароль идет в открытом виде.

oz.by по HTTPS предлагает принять самоподписанный сертификат, чтобы потом произвести редирект на HTTP. Пароль в открытом виде.

Вот такая статистика. Западные ресурсы и пользователи давно освоили основы безопасности в сети. Ведущие российские ресурсы защищают хотябы авторизацию пользователя. Ведущие белорусские ресурсы безопасность пользователей игнорируют полностью.

1. Домашний сервер на Debian 5.
2. Физический доступ к нему.
3. Доступ по SSH (не root).
4. USB-флешка с разделом NTFS.

Необходимо: быстро монтировать и размонтировать флешку для чтения/записи.

Вся проблема сводится к тому, что автомантирование флешек в Дебиане по дефолту делается штатными драйверами (read-only) и только с правами на монтирование. А мне необходимо было периодически скидывать инфу на флешку или с нее. Захотелось процесс оптимизировать.

Для достижения цели необходимо решить 2 задачи:

1. дать доступ к монтированию флешек (не всего, что попало, а именно USB NTFS флешек) рядовому пользователю без пароля,
2. избавить от необходимости полностью писать команду монтирования каждый раз.

Делается все очень просто. Я создал shell-скрипт /root/flash следующего содержания:

#!/bin/bash

case "$1" in
	1)
		mount -t ntfs-3g /dev/sdc /media/flash/
		;;
	0)
		umount /media/flash/
		;;
	*)
		echo $"Usage: $0 {1|0}"
		exit 1
esac

При передаче скрипту 1 происходит монтирование, при передаче 0 — размонтирование флешки (если точнее, то усройства /dev/sdc).

Ссылку на скрипт размещаем в /usr/bin для удобного доступа к нему:

# ln -s /root/flash /usr/bin/flash

Теперь надо разрешить выполнение этого скрипта без пароля от имени root с помощью sudoers. Выполните:

# sudoedit

И в файл добавьте следующие строки (замените feedbee на имя вашего пользователя):

Cmnd_Alias FLASH_CMD = /usr/bin/flash
feedbee ALL=(ALL) NOPASSWD: FLASH_CMD

Собственно, всё. Теперь из под вашего пользователя можно просто выполнить:

$ sudo flash 1

для монтирования флешки, и

$ sudo flash 0

для размонтирования.