Пара мыслей о переходе браузера Opera на WebKit

Новость о переходе Opera на новый движок весьма неожиданная. Opera — это первый интернет-обозреватель, которым я начал пользоваться после стандартного в те времена IE6. Надо сказать, что та опера была довольно неказиста. С толстой панелью, и рекламой. Но я её любил, ведь она позволяла быстрее загружать саты, открывать страницы во вкладках, и экономить дорогой dial-up трафик. В то врема движок presto не поддерживал некоторые правила CSS, но это были такие мелочи по сравнению с плюсами от использования данного браузера. Через пару лет появилась Mozilla Firefox, и между Opera и Mozilla началось соревнование: кто быстрей внедрит новые стандарты, у какого браузера удобней реализованы те или иные возможности и т.д. А теперь из гонки между тремя современными движками для браузеров Presto выбывает. С одной стороны я этому рад. Зная парней из Opera, я уверен что они будут способствовать продвижению новых стандартов в WebKit, а значит плоды их работы станут доступны и в WebKit. Такие как полная поддержка многоколоночного текста, или поддержка flex box без вендорного префикса. Это хорошо, это ускорит стандартизацию и обеспечит большее единообразие в среде разработки Web-приложений. Но с другой стороны, вместе с Presto уйдёт целая эпоха. Эпоха, когда маленькая компания сама создала продукт, более совершенный чем разработки больших корпораций(я имею в виду Netscape и Microsoft), и много лет успешно с ними соперничала. Теперь же она отказывается от собственного пути в пользу кооперации с другими разработчиками, что говорит нам о том, что уровень технологий Web поднялся на такую высоту, что маленькая компания уже не в силах развивать свой движкок. Уровень развития технологий будет расти и дальше, и всё труднее будет поддерживать сложный код в одиночку. Ждём, когда Mozilla и Microsoft тоже откажутся от своих решений в данной области в пользу кооперации своих усилий с ведущими разработчиками в данной сфере. Сейчас не всем ещё очевидно, что Opera — первая ласточка в череде отказов от попыток развития очень сложного ПО силами одной компании. Но через несколько лет вероятно сдаст позиции и Mozilla. Они уже приходят к осознанию, что они не в силах своими силами отрефакторить свой движок.

Проверка вашей сети на уязвимости открытые в нескольких реализациях протокола uPnP

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

  • Broadcom
  • Asus
  • Cisco
  • TP-Link
  • Zyxel
  • D-Link
  • Netgear
  • US Robotics

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

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

sudo apt-get install -y git ruby

Теперь клонируем самый свежий metasploit из официального репозитория(хранилища git):

git clone https://github.com/rapid7/metasploit-framework.git

Переходим в нужную директорию:

cd metasploit-framework

И запускаем сканнер:

./msfconsole

Видим что-то вроде этого:

Screenshot from 2013-02-07 17:07:39

Вводим команды, ответственные за поиcк нужных уязвимостей:


msf > use auxiliary/scanner/upnp/ssdp_msearch
msf auxiliary(ssdp_msearch) > set RHOSTS 192.168.0.0/24
msf auxiliary(ssdp_msearch) > run

Где 192.168.0.0/24 — сетка, которой управляет ваш маршрутизатор. У вас их может быть несколько. У меня это 192.168.1.0/24 и 192.168.3.0/24. По умолчанию маршрутизаторы обычно имеют адрес 192.168.1.1 — так что для большинства домашних сетей с одним маршрутизатором нужно всего лишь проверить сеть 192.168.1.0/24. Если у вас несколько маршрутизаторов/сетей — проверьте их все, на всякий случай. Помните, что самопальный маршрутизатор на основе сервачка с Linux на борту тоже подвержен данной уязвимости.

Как видите, у меня всё чисто. Тем, у кого найдётся что-то из этого списка уязвимостей:

  1. CVE-2012-5958
  2. CVE-2012-5959
  3. CVE-2012-5960
  4. CVE-2012-5961
  5. CVE-2012-5962
  6. CVE-2012-5963
  7. CVE-2012-5964
  8. CVE-2012-5965
  9. CVE-2013-0229
  10. CVE-2013-0230

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

Screenshot from 2013-02-07 17:16:01

Данные уязвимости меня обошли стороной(спасибо разработчикам OpenWRT за качественную прошивку моего TP-LINK WR-740N). Помните: забота о безопасноти — это не пранойя. Грамотный подход к обеспечению вашей безопасности в сфере IT может сильно снизить риски по потере личной или деловой информации. Проверяйте вашу сеть на уязвимые места регулярно, и этим вы сильно затрудните жизнь злоумышленников.

При составлении данного поста автор использовал следующие материалы:
Критическая уязвимость во многих роутерах различных вендоров
Установка Metasploit в Ubuntu 12.04 / Debian

Мои впечатления от недорогих колонок Genius SP-U115

Я очень люблю тишину, покой и уют. Поэтому отродясь у меня не приживались акустические агрегаты вроде музыкальных центров, или даже простых колонок. Много места занимают, а толку от них я не видел. Мне, для разговоров по skype и просмотра видео, хватало гарнитуры Sven HM 40 BK. Которая звучит заметно лучше недорогой акустики. Всё было хорошо, пока я не столкнулся с задачей, как показать родственникам видео(когда у меня в наличии только наушники). Помогла решить данную проблему моя сестра, принёсшая колонки Genius SP-U115. Это две маленькие колоночки, стоимость которых примерно равна 10$. В общем, самая дешёвая акустика из доступной в Кишинёве. Предназначаются эти колоночки, похоже, для ноутбуков и прочих портативных компьютеров. Так, как колоночки питаются по кабелю USB, и не имеют других источников питания. Один провод втыкаем в порт USB, второй — в гнездо для наушников, и можно приступать к просмотру видео всей семьёй.

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

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

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

Фотка героев этой записи прилагается:

Фото Genius SP U115
Фото Genius SP U115

Создание grub.cfg без использования скриптов, генерирующих данный файл

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

Что обязательно должно быть в файле конфигурации GRUB2?

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


set default="0"
set timeout=10

Для указания шрифта, используемого grub2 укажите путь к файлу этого шрифта в формате pf2. Файлы шрифтов для grub2 можно найти в директории /usr/share/grub, откуда можно скопировать нужный шрифт в каталог /boot/grub/fonts(если его там у вас нет, конечно). У меня это путь к unicode.pf2, благодаря которому можно использовать в том числе и символы кириллического алфавита. Добавьте в файл grub.cfg строку:


set font="/boot/grub/fonts/unicode.pf2"

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

 
set menu_color_normal=white/black
set menu_color_highlight=black/light-gray

Ну, и напоследок, создадим два пункта для нашего меню: перезагрузка и выключение компьютера:


menuentry "Shutdown the Computer" {
    halt
}

menuentry "Reboot the Computer" {
    reboot
}

Ну, и конечно-же вам хочется глянуть на результат. Вот он:

Screenshot from 2012-12-31 15:17:08

В следующей записи я покажу, как добавить в grub.cfg код, устанавливающий графический режим, разрешение и фоновую картинку для нашего меню.

Измерение скорости записи файлов на USB флеш-накопитель(флешку) в Linux

Столкнулся я на днях с задачей: как измерить скорость работы флеш-брелка(моей любимой флешки ADATA S102/32GB Pro) в Linux? Специальных утилит для измерения скорости в Linux не обнаружил(может плохо искал), и решил я задействовать для этих целей тяжёлую артиллерию в лице утилиты dd.

Итак, измерение скорости записи на флешку состоит из двух этапов:
cd < путь до каталога, в который смонтирована наша флешка dd if=/dev/zero of=tempfile bs=5M count=1024 conv=fdatasync,notrunc Обратите внимание на bs=5M и count=1024. Параметр bs=5M говорит dd брать данные из файла-источника блоками по 5MiB(мебибайт), а параметр count=1024 указывает, сколько раз нужно повторить данную процедуру. То есть в результате на флешку записывается файл с данными из /dev/zero размером 5MiB x 1024 = 5GiB(гибибайт). Если у вас флешка меньших размеров, стоит уменьшить или размер копируемых блоков данных, или их количество. Результат измерения скорости записи(помним, что NTFS в Windows довольно неповоротливая ФС(по сравнению с FAT32), в Linux ситуация только усугубляется, и скорость работы NTFS вообще становится очень невысокой, кроме того на скорость работы флешки так-же повлияло отсутствие USB 3.0): Screenshot from 2012-12-25 15:26:00

Проверка работы загрузочной флешки(или USB-HDD) с помощью виртуальной машины Qemu

Для загрузки систем на базе x86 вы можете использовать команду:


sudo qemu-system-i386 -boot c -drive file=< наше устройство в каталоге /dev/>,cache=none -m 256

Стоит заметить, что раньше для запуска qemu с эмуляцией архитектуры x86 я мог просто набрать qemu вместо qemu-system-i386, но в Ubuntu 12.10 нет символической ссылки с qemu на qemu-system-i386, так что нужно набирать длинное название исполняемого файла.

Для ОС архитектуры x86_64, загружаемых с нашего устройства:


sudo qemu-system-x86_64 -boot c -drive file=< наше устройство в каталоге /dev/>,cache=none -m 256

Вместо команды qemu-system-< архитектура> можно использовать команду kvm(если у вас установлена виртуальная машина kvm). KVM работает заметно быстрее, чем Qemu. Но не поддерживает эмуляцию архитектур, отличных от архитектуры хоста(компьютера, на котором вы запускаете виртуальную машину), и требует поддержки аппаратной виртуализации вашим процессором. Если kvm не работает на вашем компьютере, ничего страшного. Используйте Qemu.

Параметр boot c говорит нашей виртуальной машине, что загрузка должна начинаться с жёсткого диска.

Параметр -drive file=< наше устройство в каталоге /dev/>,cache=none указывает, что в роли дискового устройства будет использован файл из каталога /dev/(как вы догадались, это наше дисковое устройство(флешка или винт), которое мы хотим загрузить в виртуальной машине). Обратите внимание на cache=none. Мы запрещаем виртуальной машине кешировать файлы с дискового устройства с которого производим загрузку. Кеширование в нашем случае должно быть отключено, иначе на этапе редактирования конфигурации загрузчика вы не будете понимать, почему в виртуальной машине постоянно загружается старая версия конфигурации. Я как-то очень нервничал из-за того, что Qemu не замечал изменения в grub.cfg, и загружал мне целый час grub.cfg, в котором был только пункт Halt.

Параметр -m 256 выделяет 256 мегабайт оперативной памяти нашей виртуальной машине. Если вы хотите протестировать загрузку Windows 8 или Ubuntu Linux, советую выставить хотя-бы 512 мегабайти, но для проверки работоспособности загрузчика даже 256 мегабайт будет очень много:)

На десерт я оставляю вам скриншот, демонстрирующий приглашение свежеустановленного на flash-брелок (вы же помните, как установить GRUB2 на флешку) загрузчика, загруженного в виртуальной машине Qemu:

Узнаём, как именуется наша флешка в каталоге /dev

Узнаём, как именуется наша флешка в каталоге /dev(к примеру, она может именоваться /dev/sda , /dev/sdb и т.д.) Для этого используем стандартные утилиты Linux, используемые для редактирования таблицы разделов на дисках.


sudo fdisk -l

На скриншоте видно, что устройство sdc имеет объём равный 31,6 Гб(а заявленный объём моего флеш-брелка ADATA S102 32Gb Pro как раз составляет 32 Гб). Что-бы убедиться, что я не ошибся, вызываю более информативную команду, которая указывает название устройств в своём выхлопе(рекомендую вместо fdisk всегда использовать parted).


sudo parted -l

Как видно, я не ошибся, и /dev/sdc — это действительно моя флешка ADATA. A /dev/sdc1 и /dev/sdc2 — это разделы, на которые я разбил доступное на ней дисковое пространство. Первый раздел(30Гб с копейками) является основным разделом, в формате NTFS. Его видно в Linux, Windows и MacOS X(должно быть видно, на маке не проверял). Второй раздел — типично линуксовый, он нужен для загрузчика, так как Grub 2 не способен загружаться с раздела NTFS, но может загружать ОС, расположенные на данном разделе.

Впечатление от просмотра Abraham Lincoln vampire hunter

Один из немногих фильмов о вампирах, который мне реально понравился. Серьёзная, местами очень даже драматическая, история в данном фильме очень органично сочетается с ураганным экшеном(в стиле таких шедевров, как «Матрица» или «Обитель Зла»). Именно это сочетание, да очень хорошо воспроизведённая историческая атмосфера времён Линкольна, и делают данный фильм(несмотря на драматические моменты биографии главного героя) не похожим на другие фильмы данной тематики. Фильм смотрится легко, на одном дыхании. Нестандартный метод борьбы Эйба с вампирами хоть и кажется немного нелепым, но очень органично вписывается в общую картину. В общем, Тимур Бекмамбетов снял ещё один шедевр. Который определённо стоит посмотреть в компании друзей(запасайтесь поп-корном, господа).

Сбой работы сервера, обеспечивающего работу данного сайта

Сегодня набрал адрес этого сайта, а сервер(приложение работает на OpenShift) выдал 503-ю ошибку. Похоже даже мощности Amazon и програмные решения от RedHat могут подвести. Собственно, скриншот ошибочки:

В логах встречаются предупреждения такого характера:


[Wed Oct 24 12:55:11 2012] [notice] SELinux policy enabled; httpd running as context unconfined_u:system_r:libra_t:s0:c4,c144
[Wed Oct 24 12:55:12 2012] [notice] mod_bw : Memory Allocated 32 bytes (each conf takes 32 bytes)
[Wed Oct 24 12:55:12 2012] [notice] mod_bw : Version 0.8 - Initialized [1 Confs]
[Wed Oct 24 12:55:13 2012] [notice] Apache/2.2.15 (Unix) configured -- resuming normal operations

Но причины 503-й ошибки я так и не нашёл. После перезапуска приложения командой


rhc app restart -a blog

всё встало на свои места. Но до причины сбоя так и не удалось докопаться. Может, PHP и MySQL были остановленны из-за банальной перегрузки сервера(значит OpenShift может мониторить состояние сервера, и сам отключает приложение, которое потребляет много ресурсов). Похоже, прийдётся использовать монитор работоспособности сайтов от Google, что-бы получать уведомления, как только сайт отрубится…