Какой бензин лить, 92 или 95?

Прошёлся тут в гугле в поисках истины по означенному вопросу. В основном рассуждения по разным форумам. Из более или менее объективных материалов попались два.

Первый — серия «Разводка на бензине» цикла передач «Среда обитания». Они взяли две одинаковых «Калины», загнали их на сервис на проверку и настройку, чтобы машины были технически исправны. Затем заправили на одной заправке одну 92-ым, вторую 95-ым бензином и отправили из Москвы в Питер. Получилось, что машина на 92-ом бензине прошла меньше, чем на 95-ом. Таким образом, несмотря на то, что 92-ой бензин дешевле, фактически получается, что расход его на 100 км больше, чем 95-ый, и фактически по расчётам «Среды обитания» то на то по деньгам и получилось.

Журнал «Авторевю» получил ещё более интересные результаты:> Конечно, мы ожидали увидеть разницу, но чтобы такую… Оказалось, что Solaris при работе на бензине АИ-95 экономичнее на 1,9 л/100 км (разница в 15,6%), а Sandero — аж на 4,1 л/100 км (27,3%)! Если провести несложную арифметическую операцию, перемножив среднюю стоимость бензина (26 рублей за литр АИ-92 и 28 рублей за литр АИ-95) с цифрами абсолютного расхода топлива, выяснится, что сто километров на Солярисе на «девяносто пятом» обойдутся на двадцать пять рублей дешевле, чем на «девяносто втором». А для Renault экономия еще существеннее — разница более 80 рублей!

Конечно, все зависит от режима движения. Мы повторили эксперимент, пройдя на каждом автомобиле по 300 км с максимальной постоянной скоростью: разница в расходе топлива составила всего 0,4—0,6 л/100 км (3—4%). То есть в этом случае ездить на бензине АИ-95 было бы дороже. Но то, что его расход снова оказался меньше, — это факт.

А есть ли отличия в динамике? Для Hyundai с более мощным и современным двигателем они невелики: всего 3 км/ч выигрыша по максимальной скорости и чуть больше секунды при разгоне с 80 до 120 км/ч на пятой передаче — без точных приборов этого можно и не заметить. А вот владельцу Renault Sandero, если он не хочет потерять в динамике, бензин АИ-92 противопоказан. На «девяносто пятом» Sandero быстрее на 8 км/ч, но главное, разница в эластичности на той же пятой передаче — аж семь секунд! Если на столько же продлится обгон фуры на двухполосном шоссе — это уже серьезно.

Управление Hyper-V из-под обычного пользователя

Локальное управление

В блоге Алексея Кибкало вычитал полезную штуку — как позволить простому смертному пользователю, не обладающему администраторскими правами, управлять Hyper-V, создавать и запускать виртуальные машины и так далее.

Hyper-V может хранить настройки модели авторизации в Active Directory или в локальном файле в формате XML. По умолчанию после установки роли Hyper-V настройки хранятся в файле, который находится по адресу: %programdata%\Microsoft\Windows\Hyper-V\InitialStore.xml. Для того, чтобы изменить настройки, вам потребуется:- Запустить приложение MMC. (Для этого выберите пункт Run в Start Menu или нажмите комбинацию клавиш 'Windows Key + R', затем выполните mmc.exe). - В меню File выбрать Add/Remove Snap-in.. - Добавить Authorization Manager.. - В дереве консоли (левой панели ) выбрать Authorization Manager, затем в меню , затем в меню Action выбрать пункт выбрать пункт Open Authorization Store.. - Выбрать XML file в предлагаемом диалоге в предлагаемом диалоге Select the authorization store type: и открыть файл по указанному выше пути. (Папка %programdata% является скрытой, так что проще будет скопировать путь целиком). и открыть файл по указанному выше пути. (Папка %programdata% является скрытой, так что проще будет скопировать путь целиком). - Выберите InitialStore.xml, затем , затем Microsoft Hyper-V services, далее , далее Role Assignments и в конце концов и в конце концов Administrator.. - В меню Action выберите выберите Assign Users and Groups, затем , затем From Windows and Active Directory, далее выберите пользователя, которому хотите делегировать права на управления Hyper-V. Нажмите OK и закройте окно MMC. (При этом можно сохранить или отменить настройки MMC. Это не повлияет на изменения, внесенные вами в модель авторизации)., далее выберите пользователя, которому хотите делегировать права на управления Hyper-V. Нажмите OK и закройте окно MMC. (При этом можно сохранить или отменить настройки MMC. Это не повлияет на изменения, внесенные вами в модель авторизации).

Удалённое управление
Как показала практика, это работает для случая, когда Hyper-V управляется локально. Для того, чтобы подключаться к нему удалённо, нужно проделать ещё ряд мероприятий:

Описанные в этой статье шаги применимы к версии RC0 гипервизора Hyper-V и RC0 версии клиентской утилиты управления Hyper-V Manager для Vista SP1 (x86 и x64).

Итак, на сервере следует выполнить следующие шаги:

Разрешить в Windows Firewall правило «Windows Management Instrumentation (WMI)» следующей командой:
netsh advfirewall firewall set rule group=«windows management instrumentation (wmi)» new enable=yes

Внимание: в различных локализованных ОС встроенные правила брандмауэера могут назваться по-разному. Необходимо указать название правила именно так, как оно выглядит в инструментах управления Windows Firewall. Например, в русской версии Windows Server 2008 приведенная выше строка будет выглядеть так:

netsh advfirewall firewall set rule group=«Инструментарий управления Windows (WMI — входящий трафик)» new enable=yes

Предоставить пользователю права на удаленный запуск (remote launch and activation) в DCOM. Это можно сделать как для конкретного пользователя или группы, так и для всех AUTHENTICATED USERS.
Нажмите Start, выберите Run, запустите dcomcnfg.exe.
В Component Services раскройте Computers, правой кнопкой нажмите на My Computer и выберите в меню пункт Properties.
В My Computer Properties раскройте COM Security.
В Launch and Activation Permissions выберите Edit Limits.
В случае, если пользователь не указан в списке Groups of user names в окне Launch Permission, добавьте его кнопкой Add.
В Launch Permission выберите пользователя или группу и в колонке Allow в Permissions for user укажите Remote Launch и Remote Activation. Нажмите OK.
Предоставить пользователю права на удаленное управление (remote enable) в пространстве имен (namespace) root\CIMv2 и root\virtualization. Это можно сделать как для конкретного пользователя или группы, или для AUTHENTICATED USERS.
В 
Control Panel зайдите в Administrative Tools и запустите Computer Management.
В 
Computer Management раскройте Services and Applications, правой кнопкой выберите WMI Control и нажмите Properties.
В закладке
Security выберите Advanced.
В случае, если пользователь не указан в списке
Permission в окне Advanced Security Settings, добавьте его кнопкой Add.
В 
Advanced Security Settings выберите имя пользователя и нажмите Edit.
В выпадающем меню
Apply To окна Permission Entry выберите This namespace and subnamespaces и укажите Remote Enable в колонке Allow. Нажмите OK.
Предоставьте пользователю права на Hyper-V. Эта процедура описана выше.
Перезагрузите сервер. (Если вы хотите избежать перезагрузки сервера, достаточно перезапустить следующие сервисы:
winmgmt, vmms, vhdsvc & nvspwmi).
Внимание: если сервер с установленной ролью Hyper-V, которым вы хотите управлять удаленно, используя локальную запись с правами администратора, не входит в домен, и при этом на сервере включен
User Account Control (UAC)**, то имейте в виду следующее. По умолчанию к локальным учетным записям при неинтерактивном (в том числе сетевом) доступе применяется UAC Filtering. То есть, даже если вы являетесь администратором сервера, при попытке удалённого подключения UAC предоставит вам права стандартного пользователя. Поэтому в таком случае вам потребуется напрямую предоставить пользователю права на Hyper-V способом, описанным в предыдущей статье.

Итак, сервер мы настроили. Теперь ряд настроек потребуется выполнить и на клиентском ПК с Vista SP1.

Разрешить на Windows Firewall правило «Windows Management Instrumentation (WMI)» командой
netsh advfirewall firewall set rule group=«windows management instrumentation (wmi)» new enable=yes

В русской версии Windows Vista эта же команда выглядит следующим образом:

netsh advfirewall firewall set rule group=«Инструментарий управления Windows (WMI — входящий трафик)» new enable=yes

А на системах с ОС, предшествующими Windows Vista (Windows XP / 2003), для этого служит команда

netsh firewall set service RemoteAdmin enable

На системах с ОС, предшествующих Vista (Windows XP / 2003), следует также добавить исключение для исполняемого файла Unsecapp.exe:
netsh firewall add allowedprogram program=%windir%\system32\wbem\unsecapp.exe name=UNSECAPP

Добавить в Windows Firewall исключение для исполняемого фалйла mmc.exe:
netsh firewall add allowedprogram program=%windir%\system32\mmc.exe name=«Microsoft Management Console»

Если клиент или сервер находятся в рабочей группе или они находятся в разных доменах, между которыми нет доверительных отношений, то соединение от сервера до клиента, устанавливаемое для доставки результирующей информации, происходит анонимно. Анонимное соединение завершается неудачно с кодом ошибки 0x80070005 или 0x8007000e до тех пор, пока анонимному соединнеию не будет дано право Remote Access на DCOM клиента. Дать это право можно, выполнив следующие шаги:
Нажмите Start, выберите Run, запустите dcomcnfg.exe.
В Component Services раскройте Computers, правой кнопкой выберите My Computer и укажите Properties.
В My Computer Properties раскройте COM Security.
В Launch and Activation Permissions выберите Edit Limits.
В окне Access Permissions выберите ANONYMOUS LOGON в списке Group or user names. В колонке Allow в Permissions for User укажите Remote Access и нажмите OK.
После выполнения всех описанных действий вы, наконец, получите возможность удаленно подключаться к серверу и управлять ролью Hyper-V.

Настройка MikroTik под Корбину

Поскольку грёбаная корбина извращённо создаёт pptp/l2tp соединения, с настройкой их интернета НЕ под виндой перманентно возникают грабли. Из-за того, что корбина в качестве дальнего конца туннеля подставляет адрес их VPN-сервера, каковой и делается шлюзом по умолчанию, то при подъёме туннеля пакеты VPN пытаются идти не по локалке, как должны, а внутри самого туннеля. Из-за этого соединение рвётся. Я с этим научился бороться на FreeBSD с помощью статических маршрутов к VPN-серверам и правки на ходу шлюза по умолчанию после подъёма соединения.

В конторе купили маршрутизаторы MikroTik RB750. Мега-вещь, кстати. И надо их как-то настроить, чтобы они раздавали интернет корбиновский в офисе. Но сходу фокус не прокатил, в силу описанных выше причин. Поиск по интернету привёл к очень толковой методичке, разработанной неким ООО «Виджет-Про». За что выражаю им благодарность перед строем с занесением в карму.

От себя добавлю, что нужно также в настройках dhcp-клиента на WAN-интерфейсе убрать галку «Add default route», иначе в системе получалось два машрута по умолчанию, и хотя VPN не отваливался, но интернета всё равно не было.

Настройка виртуальных пользователей vsftpd под freebsd

Нашёл тут вменяемую методичку, как настроить vsftpd под FreeBSD, чтобы он авторизовал не системных, а виртуальных пользователей по файлу с паролями. Оказывается, с этим есть ряд проблем, потому что в документации самого vsftpd описывается способ через модуль pam_userdb, а его во фре нет. В методичке используется pam_pwdfile.

UPD от 22.04.2014: Надо только добавить, что почему-то перестала работать авторизация виртуальных юзеров, если пароли в базе сохранены в виде md5. Какой-то то ли косяк, то ли фича в pam_pwdfile. Приходится создавать пароли в формате crypt():

htpaswd -b -c -d /etc/vsftpd_login.db user1 user1password

Только тогда авторизация работает. Причём вроде как когда на 8-ой фре это настраивал, md5 нормально переваривался, а на 10-ой сейчас пробую — не работает, только crypt принимает.

Ошибка при обращении к компу по SMB, указав его DNS-псевдоним, а не NetBIOS-имя

Создаём в DNS псевдоним mega-comp.domain.tld для компьютера \comp, пишем в командной строке: ping mega-comp.domain.tld и видим, что всё чотко пингуется. Затем пытаемся обратиться к нему по NetBIOS: \mega-comp.domain.tld, и получаем облом в виде сообщения: «Не удалось подключиться к сети из-за существования совпадающих имен. Измените имя компьютера на Панели управления и повторите попытку

Это официальная бага, признана Microsoft'ом, и они божатся, что исправили её ещё начиная в Win2k SP3. Однако эти грабли всплыли и на сервере с Win2k8. Лечится прописыванием у компа \comp в реестре следующего параметра:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters\DisableStrictNameChecking=1

Если параметра нет, его нужно создать.

После этого можно перезагрузить сервер, ну или перезапустить службы «Сервер» и «Рабочая станция».

Перевод статьи «Processor scaling»

Выкопал тут в одном из номеров жернала BSD magazine статью про возможность управлять частотой процессора во FreeBSD. Информация меня приколола и после ряда экспериментов на натуре решил статью перевести.

Here we go.

Slawomir Wojciech Wojtczak (имя автора транскрибировать я не рискнул :-) )

FreeBSD, как и многие другие современные ОС семейства Unix предлагают возможность управления частотой процессора для уменьшения потребляемой процессором электроэнергии и тепловыделения (что косвенно также снижает потребление энергии).

В сравнении с другими системами, такими как Solaris или семейство Linux'ов, которые в точности следуют определёнными фирмой Intel C- и P-состояниями (C-states and P-states) процессора, FreeBSD пошла немножко дальше, и даёт возможность пользователю установить любую частоту процессора, на которой этот процессор в состоянии работать. Это может несколько сбивать толку, но всё станет ясно после прочтения следующего абзаца.

Давайте посмотрим, какие частоты Intel нам рекомендует для использования в процессоре T7300 2 ГГц: 800, 1200, 1600, 2000 МГц. Эти «ступеньки» частот доступны в упомянутых выше операционных системах, но FreeBSD предлагает следующий набор частот на этом же самом процессоре: 150, 300, 450, 600, 750, 900, 1050, 1200, 1400, 1600, 1750, 2000, что означает более широкие возможности в энергосбережении и бОльшую гибкость при выборе желаемой частоты. В случае использования одного и того же процессора Intel E6320, который, конечно же, поддерживает технологию Intel SpeedStep, Solaris или Linux предлагают использовать частоту 1600 или 1866 МГц, тогда как FreeBSD может начать с 250 МГц…

Включаем
Демон FreeBSD, который называется powerd(8), и отвечает за управление частотой процессора, по умолчанию отключён. Чтобы включить его при прочих настройках по умолчанию (которые довольно неплохи, кстати), нужно проделать следующие действия: добавить строку powerd_enable=«YES» в файл /etc/rc.conf, и, собственно, запустить сам демон:

box# /etc/rc.d/powerd startStarting powerd.box#

Проверим, действительно ли powerd(8) запустился:

box# pgrep powerd893box#

Для управления частотой нужно, чтобы ядро было скомпилировано с указанием опции cpufreq (которая по умолчанию включена в ядре FreeBSD, начиная с версии 7.1-RELEASE), либо должен быть загружен модуль cpufreq, если ядро было собрано без указания этой опции.

Вы можете сконфигурировать демон powerd(8) переключаться между более высокой и более низкой частотами процессора, в зависимости от текущей загрузки процессора, причём если вас не устраивают пороги переключения частот по умолчанию, вы можете задать свои. Делается это с помощью задания соответствующих значений для параметра powerd_flags в файле /etc/rc.conf. За подробностями можно обратиться к странице руководства man powerd.

powerd_flags=»-i 85 -r 60 -p 100»

Итак, мы запустили демон powerd(8), теперь он управляет частотой нашего процессора. Чтобы посмотреть, в каких пределах powerd(8) может менять частоту процессора, нужно выполнить команду:

box# sysctl dev.cpu.0.freq_levels
dev.cpu.0.freq_levels: 2000/31000 1750/27125 1600/22000 1400/19250 1200/13000 1050/11375 900/9750 750/8125 600/6500 450/4875 300/3250 150/1625
box#

И, конечно же, мы можем выключить powerd(8), и установить желаемую частоту вручную, типа того:

box# /etc/rc.d/powerd stopStopping powerd.box# sysctl dev.cpu.0.freq=450dev.cpu.0.freq: 2000 -> 450box#

Итак, подведём итоги: модуль ядра cpufreq позволяет нам устанавливать другие частоты работы процессора, а не только те, что предусмотрены в процессоре по умолчанию, и демон powerd(8) может автоматически менять частоту процессора в зависимости от текущей загрузки CPU, что позволяет экономить энергию.

Устанавливаем минимальную частоту
Мы можем установить минимальную частоту, которую нам бы хотелось, чтобы powerd(8) использовал. Для этого потребуется изменить значение параметра sysctl, который называется debug.cpufreq.lowest. Также можно прописать изменение этого параметра в файле /boot/loder.conf, чтобы это изменение стало постоянным и автоматически включалось после перезагрузки системы. Но можно минимальную частоту установить и без перезагрузки, для этого придётся всего лишь перезапустить powerd(8), чтобы он узнал о том, что минимальная частота установлена другая (см. Listing 1):

Listing 1. Устанавливаем минимальную частоту.box# sysctl dev.cpu.0.freqdev.cpu.0.freq: 150box# sysctl debug.cpufreq.lowestdebug.cpufreq.lowest: 0box# sysctl debug.cpufreq.lowest=450debug.cpufreq.lowest: 0 -> 450box# /etc/rc.d/powerd restartStopping powerd.Starting powerd.box# sysctl dev.cpu.0.freqdev.cpu.0.freq: 450box#

Устанавливаем максимальную частоту
Некоторые ноутбуки слегка перегреваются, когда их процессоры работают на максимальной скорости. Потребление энергии также достаточно велико, когда используется максимальная частота процессора. По умолчанию FreeBSD не имеет средств установить максимальную частоту процессора, но патч авторства Бориса Кочергина позволяет установить максимальную частоту процессора (highest step) (см. Листинг 2). Чтобы применить этот патч, нужно проделать несколько простых операций:

box# cd /usr/src/sys/kernbox# patch < /path/to/patchbox#

Listing 2. Патч, позволяющий установить ограничение по максимальной частоте.

—- kern_cpu.c.orig 2008-11-08 13:12:24.000000000 -0500
+++ kern_cpu.c 2008-11-08 10:33:18.000000000 -0500
@@ -131,12 +131,16 @@
DRIVER_MODULE(cpufreq, cpu, cpufreq_driver, cpufreq_dc, 0, 0);

static int cf_lowest_freq;
+static int cf_highest_freq;
static int cf_verbose;
TUNABLE_INT(«debug.cpufreq.lowest», &cf_lowest_freq);
+TUNABLE_INT(«debug.cpufreq.highest», &cf_highest_freq);
TUNABLE_INT(«debug.cpufreq.verbose», &cf_verbose);
sysctl_NODE(debug, OID_AUTO, cpufreq, CTLFLAG_RD, NULL, «cpufreq
debugging»);
sysctl_INT(_debug_cpufreq, OID_AUTO, lowest, CTLFLAG_RW, &cf_lowest_freq,
1,
«Don't provide levels below this frequency.»);
+sysctl_INT(_debug_cpufreq, OID_AUTO, highest, CTLFLAG_RW, &cf_highest

freq, 1,
+ «Don't provide levels above this frequency.»);
sysctl_INT(_debug_cpufreq, OID_AUTO, verbose, CTLFLAG_RW, &cf_verbose, 1,
«Print verbose debugging messages»);

@@ -295,6 +299,14 @@
goto out;
}

  • / Reject levels that are above our specifed threshold. /
  • if (cf_highest_freq > 0 && level->total_set.freq > cf_highest_freq)
    {
  • CF_DEBUG(«rejecting freq %d, greater than %d limit\n»,
  • level->total_set.freq, cf_highest_freq);
  • error = EINVAL;
  • goto out;
  • }
  • / If already at this level, just return. /
    if (cpufreq_CMP(sc->curr_level.total_set.freq, level->total_set.freq)) {
    CF_DEBUG(«skipping freq %d, same as current level %d\n»,
    @@ -617,8 +629,13 @@
    continue;
    }

    — / Skip levels that have a frequency that is too low. /
  • if (lev->total_set.freq < cf_lowest_freq) {
  • /*
    • Skip levels that have a frequency that is too low or too
    • high.
  • */
  • if (lev->total_set.freq < cf_lowest_freq ||
  • (cf_highest_freq > 0 &&
  • lev->total_set.freq > cf_highest_freq)) {
    sc->all_count—;
    continue;
    }
    Теперь нужно пересобрать ядро (или только модуль cpufreq, если вы не включали эту опцию в ядре). За подробностями в этом процессе можно обратиться к FreeBSD Handbook. После перезагрузки системы или модуля cpufreq в sysctl появится параметр debug.cpufreq.highest, который можно использовать для установления максимальной частоты процессора с помощью powerd(8). Как и в случае с минимальной частотой, наилучшим местом для установления значения максимальной частоты, является файл /boot/loader.conf. После того, как вы установите максимальную и минимальную частоты, список доступных частот, которые выводятся при опросе параметра dev.cpu.0.freq_levels, будет ограничен этими значениями:
box# sysctl dev.cpu.0.freq_levels dev.cpu.0.freq_levels: 1200/13000 1050/11375 900/9750 750/8125 600/6500box#

В приведённой ниже таблице можно посмотреть таблицу распределения потребления энергии процессором T7300, в зависимости от частоты. Все измерения проведены внешним прибором для измерения мощности. Ноутбук работал только от сети, потребление при работе от батареи не измерялось. Конечно же, процессор в момент измерения был загружен на 100% 4-мя процессами python, вычисляющими значение 999999999999 в степени 999999999999 (см. Table 1).
/assets/images/table1.png

Похоже, что частота 1200 МГц — наилучшая для использования на данном типе процессоров, все более высокие частоты резко увеличивают энергопотребление.

Я также измерил потребление в режиме простоя процессора, но отличие в энергопотреблении даже между крайними частотами 150 Гц и 2000 МГц слишком невелико — около 3 ватт, из чего следует, что важнейшим критерием является потребление процессора в режиме максимальной нагрузки.

Используем C-состояния (C-states)
Теперь мы знаем, как изменять частоту, с которой работает процессор. Пришло время научиться изменять C-состояния, которые определяют разные уровни «засыпания» процессора (точнее, его ядер), когда он какое-то время находится в состоянии простоя. Ниже приведена таблица, в которой перечислены все С-состояния, которые доступны для процессора Intel T7300. Более новые версии платформы Montevina имеют даже больше C-состояний, с ещё более глубокой степенью «засыпания» (см. Table 2).
/assets/images/table1.png

Чтобы узнать, какие С-состояния поддерживаются и доступны из FreeBSD для вашего типа процессора, выполните следующую команду:

box# sysctl dev.cpu.0.cx_supporteddev.cpu.0.cx_supported: C1/1 C2/1 C3/57 box#

Видно, что в нашем случае FreeBSD поддерживает состояния с C0 до C3, и можно получить/установить самое «низкое» C-состояние для каждого ядра. Делается это следующим образом:

box# sysctl dev.cpu.0.cx_lowestdev.cpu.0.cx_lowest: C1box# sysctl dev.cpu.0.cx_lowest=C3dev.cpu.0.cx_lowest: C1 -> C3box# sysctl dev.cpu.1.cx_lowestdev.cpu.1.cx_lowest: C1box# sysctl dev.cpu.1.cx_lowest=C2dev.cpu.1.cx_lowest: C1 -> C2box#

Существует, правда, одна тонкость, которую вы должны знать про C-состояния. Если вы переведёте процессор в наиболее «глубокое» С-состояние (в приведённом примере это состояние C3), тачпад ноутбука будет слегка притормаживать, прежде чем его можно будет использовать (задержка будет составлять примерно 1 секунду), что может с течением времени начать сильно раздражать. Решением будет перевод одного ядра процессора в состояние, которое обеспечит меньшую задержку для «просыпания». В данном примере это состояние C2. Все остальные ядра можно перевести в состояние наиболее «глубокого» сна из доступных состояний, чтобы обеспечить максимально возможную экономию энергии.

Чтобы сохранить все эти изменения и после перезагрузки, как обычно, можно воспользоваться файлом /boot/loader.conf. Можно также посмотреть статистику использовать C-состояний следующей командой:

box# sysctl dev.cpu.0.cx_usagedev.cpu.0.cx_usage: 0.00% 0.04% 99.95%box# sysctl dev.cpu.1.cx_usagedev.cpu.1.cx_usage: 0.00% 100.00% 0.00%box#

Другие параметры
Можно также понизить частоту таймера ядра, изменяя параметр sysctl(8) kern.hz со значения по умолчанию 1000, например, до 100. Но это можно сделать только на этапе загрузки системы, так что нужно добавить строчку kern.hz=100 в файл /boot/loader.conf и перезагрузиться. Предполагается, что в будущем значение kern.hz, равное 100, станет дефолтным, но мы, похоже, не увидим этого до 8.0-RELEASE (к слову, в 8.0-RELEASE значение kern.hz таки равно 1000). Ещё можно сделать одну штуку, которая сильно зависит от процессора — это монтировать файловые системы с опцией noatime.

И несколько слов для владельцев процессоров AMD. FreeBSD также поддерживает возможность управления частотами для этих процессоров, используя технологию AMD Cool'n'Quiet. Она работает точно так же, как и описано для процессоров Intel в этой статье.

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

Сеть по bluetooth с помощью btpand

В упомянутом уже ThinkPad 600X сетки не было. Точнее, сетевая PCMCIA была, но товарищ не нашёл проводочек, который подключается одним концом к сетевухе, а другим — к коннектору RJ-45. Поскольку CDROM в ноуте старый и довольно глючный, пришлось что-то придумывать. Вариант был ровно один — поскольку USB-порт там один есть, остаётся только Bluetooth, ну, или всякие USB-сетевые, проводные или WiFi. Покупать для этого ноута USB-сетевую меня заломало — не такая уж важная птица, а адаптеров голобуго зуба у меня навалом.

Под фрёй 7.2 я настроил сетку с помощью LAN over PPP, настроил rfcomm_pppd и полетели. Запускалось оно несколько криво — из rc.local, и требовало ещё не менее трёхсекундной паузы для прописывания маршрутизации, но в общем, работало.

После перехода на 8-ую фрю начали наблюдаться проблемы — примерно через час прослушивания интернет-радио голубозубый линк отваливался, и не поднимался до тех пор, пока я не выдерну и не вставлю обратно bluetooth-адаптер на серверной стороне, с последующим перезапуском rfcomm_pppd с обоих сторон. Разбираться с этим бесполезно — никаких сообщений в логах нет, ничего не происходит, сервер по голубому зубу при обзоре устройств виден, и линк поднимается, но трафика по нему не идёт. Я такое уже видел, правда, с КПК, но побороть так и не смог. Решил перейти на btpand, раз уж он появился — это софтина, портированная во фрю из NetBSD (не прошло и 8 лет, как фря наконец-то начала вкуривать BT PAN, ггг).

Потестил btpand при ручном запуске. На сервере запускаем:

ifconfig tap0 create

btpand -d ubt0 -i tap0 -s NAP

ifconfig tap0 192.168.2.1 netmask 255.255.255.0

На клиенте:

ifconfig tap0 create

btpand -d ubt0 -i tap0 -s NAP -a 00:18:e7:1a:24:9b

ifconfig tap0 192.168.2.2 netmask 255.255.255.0

Ну, тут всё понятно — создаём интерфейс tap0, через который будет работать голубозубый линк, поднимаем сам линк, и затем конфигурируем интерфейсы — прописываем IP-адрес, на котором оно будет работать.

Проверяем наличие присутствия связи:

notebook# ping -c 4 192.168.2.1
PING 192.168.2.1 (192.168.2.1): 56 data bytes
64 bytes from 192.168.2.1: icmp_seq=0 ttl=64 time=22.778 ms
64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=18.257 ms
64 bytes from 192.168.2.1: icmp_seq=2 ttl=64 time=39.277 ms
64 bytes from 192.168.2.1: icmp_seq=3 ttl=64 time=18.313 ms

Типа, работает, что ли? Афигеть... :-)

Ну чо, подадим на ноут интернет теперь — пропишем nameserver на ноуте в /etc/resolv.conf, а серверный голубозубый IP-шник в качестве шлюза и перенастроим правила файрвола, чтобы он ноут пускал в интернет:

route add default 192.168.2.1

Проверяем:

notebook# ping ya.ru
PING ya.ru (77.88.21.8): 56 data bytes
64 bytes from 77.88.21.8: icmp_seq=0 ttl=57 time=85.294 ms
64 bytes from 77.88.21.8: icmp_seq=1 ttl=57 time=74.188 ms
64 bytes from 77.88.21.8: icmp_seq=2 ttl=57 time=217.258 ms

Круто! Грузим KDE и пытаемся открыть http://shoutcast.com Получаем облом. Сайт грузится, но не до конца, и запустить прослушивание чего-нибудь оттуда невозможно — даже плейлист не качается. Интуиция подсказывает, что раз что-то работает, а что-то нет при живом линке, то это проблемы с MTU. Начинаю гонять пинги разного размера, определяя, какой максимальный размер пинга пройдёт. Оказалось, что пинги размером 641 байт проходят, и больше — хрен. А MTU на интерфейсах tap0 выставился дефолтный в 1500. Мораль — надо копать. Накопал только вот это. Симптомы там у товарища в точности как у меня — MTU в районе 600 байт, иначе хеликоптер нихт. Но потом он перезагрузил телефон, к которому подключал комп по BT, и чудесным образом всё заработало с правильным MTU 1500. Но у меня такая маза не прокатила — сразу после перезагрузки оно вроде заработал с MTU 1500, но через пару минут всё отвалилось, в том числе ssh. Так что на текущий момент MTU 640 является обязательным.

Ну, теперь надо как-то организовать, чтобы вся эта хрень запускалась при старте системы. Условия у меня довольно специфические — в сервере BT-адаптер торчит всегда, а в ноуте — практически всегда, потому что я его в качестве плейера радива из интернета использую. Значит, надо либо в rc.local вписывать, что проще, но криво, либо написать rc-скрипт. Поскольку лёгких путей мы не ищем, то я выбрал второй вариант.

Скрипт будет принимать такие параметры:

btpand_enable — разрешено или нет запускать btpand (по умолчанию NO);
btpand_device — девайс bluetooth, с которого работаем;
btpand_interface — интерфейс, на котором работать (по умолчанию tap0);
btpand_servicebtpand_service — сервис, который мы используем (GN, NAP, PANU, по умолчанию NAP);
btpand_linkup — скрипт, выполняемый при установлении соединения;
btpand_linkdown — скрипт, выполняемый при разрыве соединения;
btpand_server — MAC-адрес сервера, к которому будем подключаться, если работаем как клиент;
btpand_iface_addr — это параметр для конфигурирования интерфейса — прописывания IP-адреса и пр. Синтаксис такой же, как и у параметров rc.conf типа «ifconfig_rl0» — эта строка просто скармливается ifconfig'у.

Скрипты linkup/linkdown мне нужны, чтобы прописывать шлюз по умолчанию. В других задачах, возможно, потребуется ещё что-нибудь делать. Это необязательный параметр. Как, в общем, и многие другие. Обязательным будет являеться только btpand_enable и btpand_iface_addr для обоих компов, и btpand_server — только при запуске на клиенте. Остальное либо не обязательно, либо конфигурируется по умолчанию, как параметр btpand_interface.

Собственно, родился такой несложный скрипт:

!/bin/sh

PROVIDE: btpand

REQUIRE: DAEMON sdpd

BEFORE: LOGIN

KEYWORD: nojail

. /etc/rc.subr

name=«btpand»
rcvar=set_rcvar
command=«/usr/sbin/btpand»

load_rc_config $name

eval «${rcvar}=\${${rcvar}:-'NO'}»

btpand_interface=${btpand_interface:-«tap0»}
btpand_device=${btpand_device:-«ubt0hci»}
btpand_service=${btpand_service:-«NAP»}
btpand_server=${btpand_server:-«no»}
btpand_iface_addr=${btpand_iface_addr:-«dhcp»}
btpand_linkup=${btpand_linkup:-«no»}
btpand_linkdown=${btpand_linkdown:-«no»}

start_cmd=«btpand_start»
stop_precmd=«btpand_stopprecmd»
stop_postcmd=«/sbin/ifconfig ${btpand_interface} destroy»

btpand_start()
{
if [ ! -e /dev/${btpand_interface} ]
then /sbin/ifconfig ${btpand_interface} create
fi
/sbin/ifconfig ${btpand_interface} mtu 640
if [ «dhcp» = «${btpand_iface_addr}» ]
then /sbin/dhclient ${btpand_interface}
else /sbin/ifconfig ${btpand_interface} ${btpand_iface_addr}
fi
if [ «no» = «${btpand_server}» ]
then $command -d ${btpand_device} -s ${btpand_service} -i ${btpand_interface} > /dev/null 2>&1
else $command -d ${btpand_device} -s ${btpand_service} -i ${btpand_interface} \
-a ${btpand_server} > /dev/null 2>&1
fi
if [ ! «no» = «$btpand_linkup» ]
then sh ${btpand_linkup}
fi
}

btpand_stopprecmd()
{
if [ ! «no» = «$btpand_linkdown» ]
then sh ${btpand_linkdown}
fi
}

run_rc_command «$1»

Осталось это всё запустить. На сервере говорим:

echo btpand_enable=«YES» >> /etc/rc.conf

echo btpand_iface_addr=«192.168.2.1 netmask 255.255.255.0» >> /etc/rc.conf

На клиенте прописываем:

echo btpand_enable=«YES» >> /etc/rc.conf

echo btpand_iface_addr=«192.168.2.2 netmask 255.255.255.0» >> /etc/rc.conf

echo btpand_server=«00:18:e7:1a:24:9b» >> /etc/rc.conf

echo btpand_linkup=«/home/vasya/bt_linkup» >> /etc/rc.conf

И создаём файл /home/vasya/bt_linkup с таким содержанием:

!/bin/sh

route add default 192.168.2.1

Перезапускаем сервер, перезапускаем ноут — судя по лампочкам на BT-адаптере, линк поднялся. Проверяем:

notebook# ping ya.ru
PING ya.ru (77.88.21.8): 56 data bytes
64 bytes from 77.88.21.8: icmp_seq=0 ttl=57 time=66.597 ms
64 bytes from 77.88.21.8: icmp_seq=1 ttl=57 time=93.634 ms
64 bytes from 77.88.21.8: icmp_seq=2 ttl=57 time=49.616 ms

Точно, поднялся. Ну, значит, топаем в KDE и запускаем чего-нибудь с Shoutcast'a бодрое на прослушивание! :-)

Область применения

Вообще-то, это можно юзать не только для связи двух компов с фрёй между собой. BT-сервис «LAN over PPP» — довольно специфический, виндовые драйвера, которые я пробовал, его просто не видят, так что когда я захотел ноут с виндой, не имеющий WiFi адаптера, но имеющий BT, подключить в интернет через LAN over PPP, настроенный на серваке, то круто обломался.

Да и мобильные устройства далеко не все умеют LAN over PPP. Например, у меня был КПК HP hx2190 — он мог подключаться к такому сервису на сервере, и ходить через него в интернет и прослушивать музыку. А вот коммуникатор HTC Touch уже к серваку подключиться не мог — его BT-стек не поддерживает этот сервис. Touch, конечно, может работать по WiFi, который у меня всё равно в квартире есть, но WiFi гораздо более прожорлив в смысле батарейки, так что BT сильно предпочтительней, тем более что разницы в скорости между BT и WiFi линках на коммуникаторе практически незаметно.

К тому же, в коммуникаторе нет сервиса Dial-up internet, он интернет умеет раздавать только через PAN. При наличии btpand можно спокойно подключить 8-ую фрю к коммуникатору и заюзать интернет через EDGE.

Ошибки при опросе демоном hald некоторых устройств

Камрад мой один, живущий в США, передал мне с оказией свой старый-старый ноут — IBM ThinkPad 600X. Запихал в него 512 метров памяти помимо встроенных 64 метров. Решил я этот ноут приспособить для смелых экспериментов по организации десктопа не фре. Ну, заодно в качестве медиа-центра его использовать, а то таскать нетбук, являющийся сейчас основным рабочим компом между рабочим столом и «мультимедийным» — на котором стоит усилитель, колонки и большой монитор для просмотра фильмов — с определённого момента стало ломать. Поставил фрю 7.2, всё настроил — работает вроде. При просмотре фильмов на некоторых сценах изображение подёргивается, что неудивительно — процессор-то всего 500 MHz. Но это редко бывает, так что не напрягает.

Но лучшее — враг хорошего. С выходом FreeBSD 8.0 я подумал, что не грех было бы перевести всю наличную технику на неё — сервак и этот самый ноут. Поставил 8-ку на ноут, и обнаружил, что при включении hald ноут постоянно с интервалом примерно в секунду ругается на первой консоли, что acd0: FAILURE — unknown CMD (0x03) ILLEGAL REQUEST asc=0x20 ascq=0x00. И приводит это к невозможности смонтировать диски в CDROM. Полез в интернет, копался там дня три — ничего толком нет, кроме совета убрать драйвер atacdrom из ядра и воткнуть вместо него atapicam.

Я эту операцию немедленно проделал. Налицо эффект, надпись сменилась на:

unknown: FAILURE — unknown CMD (0x03) ILLEGAL REQUEST asc=0x20 ascq=0x00

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

Описаный по ссылке способ помог, ошибки перестали сыпаться. Создал файл /usr/local/share/hal/fdi/preprobe/20thirdparti/10-ignore-acd0.fdi следующего содержания:

<?xml version=«1.0» encoding=«UTF-8»?><deviceinfo version=«0.2»>  <device>    <match key=«freebsd.driver» string=«acd»>      <match key=«freebsd.unit» int=«0»>        <merge key=«info.ignore» type=«bool»>true</merge>      </match>    </match>  </device></deviceinfo>

Перезапустил hal, вроде ему полегчало, болезному. Посмотреть, какой freebsd.driver и freebsd.unit нужен, чтобы вписать в файл, можно с помощью утилиты lshal.

BackDoor.Tdss

Щас на форуме samag.ru нашёл ссылку на статью от DrWeb, описывающей живность BackDoor.Tdss. Вот эта статья. Это аццкий ад, товарищи. Если коротко, то вирус поражает файл драйвера диска (atapi.sys, или у кого там что, в зависимости от железа), и творит потом страшные вещи. Ну, обойдёмся без кровавых подробностей — там дано довольно детальное описание с перечислением функций API, областей памяти и диска, и системных компонентов винды.

Я, оказывается, уже встречался с этим зверем. И в тот раз меня спасла только моя наблюдательность — я увидел, что антивирус определил этот Tdss в файле atapi.sys и удалил файл. Учитывая, что всего с машины было убито около 6 сотен всяких врагов, это чудо, что я увидел эту строчку, и отметил в памяти факт, что atapi.sys удалён. Иначе б для меня был мега-сюрпризом факт, что система после лечения вирусов не поднялась. А так — скопировал из инсталлятора atapi.sys на родину, и всё взлетело.

CryptoPro и ошибка c000021a

Клиент поведал страшную историю про то, как к кабелю от мобильника с разъмом mini-USB попытались подключить флэшку. У него там два кабеля торчало — USB-удлинитель и этот самый кабель от мобильника, и девачка-бухгалтер их перепутала и вместо удлинителя попыталась вонзить mini-USB в разъём флэшки. Винда сказала «Кря!», а может даже и «Гав!», и повисла. После перезагрузки все увидели красивый синий экран с надписью:

STOP: c000021a { **
Windows Logon Process
Windows Logon Process ****
0x0000005 (0x000000000x00000000)

Там где звездочки — непечатное. Не в смысле матерное, а в смысле кодировка битая :-) При этом в безопасном режиме винда грузилась.

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

Ну то есть, понятно было, что падает winlogon.exe, и что падает он из-за сбоя в каком-то драйвере или библиотеке, которые он пытается всосать при загрузке. Но каком? Это вопрос.

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

Что снесло крышу до этого нормально работавшему драйверу — вопрос архи-тёмный. На этот счёт существуют разные мнения. Тут вот перечислены некоторые из них. Часть камрадов предполагает, что оно конфликтует с NOD32, часть утверждает, что на томах FAT32 драйвер КриптоПро без SP3 не работает. Я разбираться особо не стал, времени-то уже 4-ый час утра. Поэтому вынес NOD32, всё равно он не обновлялся, и сконвертил диски в NTFS, затем вернул предварительно экспортированную ветку с параметрами драйвера в реестр обратно. Всё заработало. Хотя это архи-странно, факт.