Установка разрешения экрана в grub2 при помощи 915resolution

Когда я был молод и глуп, я извращался с grub-ом, пытаясь получить родное разрешение в консоли linux на своем недобуке. Сейчас, благодаря поддержке KMS в ядре, это нафиг никому не нужно. Но ебанут красноглазым нет покоя! Итак устанавливаем родное разрешение непосредственно для grub-а, чтобы не оскорблять свой ясный взор "замыленными" шрифтами, при выборе вариантов загрузки.
На моем MSI Wind u100 конфиг загрузчика изменился так:

$ diff -urU 4 grub.cfg-old grub.cfg
--- grub.cfg-old        2010-08-19 18:35:57.000000000 +0300
+++ grub.cfg    2010-08-19 18:08:23.000000000 +0300
@@ -36,8 +36,10 @@
 insmod ext2
 set root='(hd0,msdos1)'
 search --no-floppy --fs-uuid --set d38f73d1-1c4b-4854-b640-4d80bd808903
 if loadfont /usr/share/grub/unicode.pf2 ; then
+  insmod 915resolution
+  915resolution 41 1024 600
   set gfxmode=1024x600
   load_video
   insmod gfxterm
 fi

В debian-е для этого мне понадобилось изменить 2 файла: /etc/default/grub и /etc/grub.d/00_header (я слышал за это могут и руки оторвать).
И да, перед экспериментами лучше запастись чем-нибудь вроде загрузочной флэшки, так как есть вероятность получить незагружаемую систему.

В итоге:

(как обычно, фотографировал на калькулятор)

Usbmount - автоматическое монтирование флешки

В современных linux-дистрибутивах автоматическое монтирование флешек успешно реализуется с помощью HAL (или что-там-теперь-будет-вместо-него) и DE. Те бедолаги, которые не пользуются KDE/GNOME, в качестве альтернативы, могут выбрать halevt (HAL-озависимый) или autofs (его конфиги явно не самые дружелюбные).
Отдельные умники пишут свои, порой довольно изощренные, наборы правил для udev (правда сами разработчики udev предостерегают от такого подхода). А наиболее ортодоксальные линуксоиды, возможно, все еще используют записи в fstab, наизусть помнят все опции mount, при этом брезгливо косятся в сторону HAL …и выгребают ряд проблем при одновременном подключении нескольких флешек, или при подключении незнакомых флешек с причудливыми таблицами разделов; и вообще ни про какое автоматическое монтирование здесь речь уже не идет.
Оказывается, в сторонке, довольно давно, стоит готовый велосипед под названием usbmount (http://usbmount.alioth.debian.org/). По сути это все те же скрипты, запускаемые через udev. Одновременное подключение флешки и телефона с 2-мя разделами прошло гладко. В общем, закомментировал пережитки прошлого в fstab (хотя usbmount его вполне уважает), и, надеюсь, забыл про монтирование флэшек на ближайшие несколько лет (хотя стоп! тут же exFAT наступает).

(Не)надежность master-master репликации в mysql

Перед нами встала задача обеспечить быструю и надежную работу клиентов с одной базой данных на 2-х географически удаленных объектах. В качестве одного из вариантов рассматривалась работа с 2-мя mysql серверами, которые бы реплицировались по принципу master-master. Далее рассматривается (не)надежность такой системы при одновременном изменении одних и тех же данных.

Настроим master-master репликацию (о том как это делается можно узнать из статей об основах репликации и мульти-мастер репликации).

Проведем небольшой эксперимент. Создадим таблицу
сервер1:
mysql> CREATE TABLE `new_table` (
`field1` varchar(32),
`field2` varchar(32),
`field3` varchar(32)
);
и внесем в нее начальные данные
сервер1:
mysql> SELECT * FROM new_table;
+--------+--------+--------+
| field1 | field2 | field3 |
+--------+--------+--------+
| value0 | value0 | value0 |
+--------+--------+--------+

После того как мы убедимся что БД реплицируется в обе стороны, разорвем соединение между серверами и изменим одну и ту же запись таблицы одновременно на обоих серверах.
сервер1:
mysql> UPDATE new_table SET field1='value1', field2='value1';
mysql> SELECT * FROM new_table;
+--------+--------+--------+
| field1 | field2 | field3 |
+--------+--------+--------+
| value1 | value1 | value0 |
+--------+--------+--------+
сервер2:
mysql> UPDATE new_table SET field2='value2', field3='value2';
mysql> SELECT * FROM new_table;
+--------+--------+--------+
| field1 | field2 | field3 |
+--------+--------+--------+
| value0 | value2 | value2 |
+--------+--------+--------+

После возобновления соединения и синхронизации серверов вырисовывается следующая картина:
сервер1:
mysql> SELECT * FROM new_table;
+--------+--------+--------+
| field1 | field2 | field3 |
+--------+--------+--------+
| value1 | value2 | value2 |
+--------+--------+--------+
сервер2:
mysql> SELECT * FROM new_table;
+--------+--------+--------+
| field1 | field2 | field3 |
+--------+--------+--------+
| value1 | value1 | value2 |
+--------+--------+--------+
Наблюдаем нарушение целостности данных и различия в репликах.

Альтернативные методы решения поставленной задачи можно найти в комментариях к вышеуказанным статьям (например, настройка master-slave репликации с использованием mysql-proxy или использование Multi-Master Replication Manager).

Проверка UMTS-оператора в chatscript-е

Подключаюсь к ОГО безлимит-мобильный, в котором безлимит - при регистрации в сети Utel, и помегабайтная оплата в роуминге Киевстар после превышения 40Мб лимита. Естественно есть желание проверять, в сети какого оператора зарегистрировался модем. Виндовая версия Utel-овской приблуды отображает оператора в статус-баре, линуксовую версию (найденный на просторах сети Mobile Partner) устанавливать не стал.

Подключаюсь при помощи pppd и chat. На одном буржуйском сайте, был найден список AT-команд, где есть такое:

Command: AT+COPS?,
Response: +COPS: (<mode>,[<format>,<oper>[,<act>]]),…, (<moden>,[<formatn>,<opern>[,<actn>]])
Description: Get/set current GSM/UMTS network operator, list available operators. This can be used to change for example access type and switch network.

Example:

AT+COPS=?
+COPS: (2,”3″,”3″,”24004″,2),(1,”3″,”3″,”24008″,0),(3,”Sweden 3G”,”Sweden3G”,”2)


Воспользовавшись этой информацией можно написать свой chatscript:


'' ATZ
OK-AT-OK "AT+COPS=?" UTEL3G ''
OK-AT-OK AT+CGDCONT=1,"IP","unlim.utel.ua"
OK-AT-OK "ATDT*99***1#"
CONNECT ''
'' \d\c


Terminus в ядре

Давно уже было желание вкомпилировать terminus прямо в ядро, чтобы не смотреть долгие 10 секунд на стандартный шрифт (пока не запустится один из console-* сервисов). Совсем недавно наткнулся на следующую статью, далекого 2006-го года: http://kaktyc.wordpress.com/2006/10/23/terminis-in-kernel/. Свое описание для terminus14 постараюсь выложить немного позже. Результат:


(background на tty устанавливается с помощью fbcondecor).

Устанавливаем разрешение 1024x600 во framebuffer-е linux для нетбука MSI Wind (или Asus eeePC)

Внимание, заметка устарела! Вам не нужно выполнять эти заумные штуки, описанные в заметке. В современных дистрибутивах все работает "из коробки". Можно разве что показывать внукам со словами: "Вот как оно было в 2008-м".

Стандартными методами, для фреймбуффера консоли linux, можно установить разрешение 800x600 (указать параметр ядра vga=788), но при этом на данном нетбуке консольные шрифты будут растянуты. Параметра vga=XXX для 1024x600 не существует.

Но существует хак, описанный в http://www.nathancoulson.com/proj_eee.shtml, который позволяет добиться нужного результата. По ссылке рассмотрен пример установки 800x480 для eeePC, но инструкция годится и для Wind-a (т.к. используется одинаковый чипсет 945GME). У меня это работает так (фото см. ниже).
Пара слов для вступления. Не стоит выполнять указанные тут команды без четкого представления что они делают. Приведенные команды не являются копипастом, в большинстве своем написаны по памяти и могут содержать ошибки. Все это приводится лишь для обще
75;о представления о необходимых шагах. Я не несу ответственности за негативные последствия Ваших действий.
Итак, сначала нужно применить патч grub-1.96-915resolution-0.5.2-3.patch к grub2. После этого в grub2 появится поддержка модуля 915resolution.
Я пользуюсь Debian, и оформлял для себя патченый grub в виде deb-пакета (люблю порядок), поэтому проделал ряд дополнительных необязательных действий, которые для упрощения здесь не привожу. В общем случае - качаем и распаковываем исходники grub2, переходим в полученный каталог и применяем патч

# patch -Np1 -i /path/to/grub-1.96-915resolution.patch

Если нет ошибок, собираем пропатченый grub2, удаляем старую версию загрузчика (при помощи Вашего менеджера пакетов) и устанавливаем новую (желательно также при помощи Вашего менеджера пакетов))).
Устанавливаем grub2 в загрузочную область:

# grub-install /dev/sda

Далее, насколько я понял, нужно подменить один из vga-режимов. Создаем файл 01_915resolution следующего содержания (в конечном результате в /etc/grub/grub.cfg будут автоматически добавляться 2 строки):

# cat /etc/grub.d/01_915resolution
cat << EOF
insmod 915resolution
915resolution 5c 1024 600
EOF

Значение 5c взято из выхлопа команды 915resolution -l (о ней ниже). Это может быть любое неиспользуемое значение режима с нужной глубиной цвета.
Перегенерируем /boot/grub/grub.cfg

# update-grub2

В общем на этом этапе все готово. Пробуем перегрузиться, к параметрам ядра добавляем video=intelfb vga=604
Откуда взять vga=604 написано здесь http://wiki.debian.org/DebianEeePC/TipsAndTricks, раздел "Text Mode". В общем, данное значение зависит от того что мы написали в /etc/grub.d/01_915resolution (вычисляется как 0x200+0x05c=0x25с в десятичном представлении), это тот режим, который мы подменили.
Для того чтобы не писать каждый раз параметры загрузки ядра вручную, в файле /etc/default/grub можно указать следующую опцию:
GRUB_CMDLINE_LINUX=" video=intelfb vga=604 "
после чего не забываем update-grub2.

Об утилите 915resolution. Взять её можно здесь http://www.geocities.com/stomljen/. Но на текущий момент версия 0.5.3 не знает о чипсете 945GME (который установлен в eeePC и Wind-е). Опять же, существует патч, который может её этому научить. Все описано здесь: http://wiki.debian.org/DebianEeePC/HowTo/GetNativeConsoleResolution. В принципе эта утилита нужна только один раз, чтобы выбрать неиспользуемый режим.

Прежде чем выполнять все это самостоятельно, рекомендую еще раз ознакомиться с документами по следующим ссылкам:
http://www.nathancoulson.com/proj_eee.shtml
http://wiki.debian.org/DebianEeePC/HowTo/GetNativeConsoleResolution
http://wiki.debian.org/DebianEeePC/TipsAndTricks
http://www.geocities.com/stomljen/

Что получаем в итоге:

Ниже описывается настройка samba модуля full_audit, который позволяет увидеть кто и к какому файлу обращался, кто создал, удалил или переименовал конкретный файл или каталог.
В результате настройки необходимые данные будут записываться в лог-файл /var/log/samba/log.audit.
(Настройка производилась в дистрибутиве Debian Etch, версия Samba 3.0.24).

1. В секцию [global] добавляется строка

syslog = 0

Данный параметр устанавливает приоритет сообщений, которые будут направлены в syslog. Чем выше значение, тем большее количество сообщений будет выводиться. Указав значение 0 можно отключить запись сообщений в syslog.

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

log level = 0 vfs:2


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

max log size = 0

Размер лог-файла задается в килобайтах. При достижении указанного значения файл будет переименован, путем добавления к имени файла расширения .old. Значение 0 отключает проверку размера (в данном случае необходимо самостоятельно позаботиться о размере лог-файла, к примеру, настроив соответсвующим образом logrotate).

4. Для активации модуля аудита, в секции, которая описывает расшаренный ресурс, добавляется строка

vfs objects = full_audit

В результате данные о доступе к файлам будут записываться в syslog, либо в лог-файл по умолчанию (log.smbd). Здесь же, через пробел, могут быть заданы другие VFS модули.

5. Можно указать дополнительные параметры модулю full_audit.
Префикс, сообщений в лог-файле:

full_audit:prefix = %u|%I

(каждая строка будет начинаться с user|ip_adress)
Какие ошибки должны отображаться в лог-файле:

full_audit:failure = none

(не протоколируем ошибки)
Действия пользователей, которые записываются в лог-файл:

full_audit:success = connect disconnect opendir mkdir rmdir closedir open close read pread write pwrite sendfile rename unlink chmod fchmod chown fchown chdir ftruncate lock symlink readlink link mknod realpath

Параметры, позволяющие управлять записью в журналы демоном syslogd:

full_audit:facility = local5
full_audit:priority = notice

Данные два параметра описывают селектор, он обозначает программу ("средство" в терминологии системы syslog), которая посылает регистрационное сообщения и уровень серьезности этого сообщения.
Прим. Несмотря на опцию syslog = 0, samba направляет сообщения в syslog. Возможно в других версиях samba такое поведение будет изменено. Последние два параметра модуля full_audit позволят в дальнейшем исключить попадание нежелательных сообщений в журанал syslog.

Собрав все вместе получим примерно следующее:

[global]
...
log level = 0 vfs:2
max log size = 0
syslog = 0
...
[incomig]
comment = Samba server's incoming directory
writable = yes
locking = no
path = /home/samba/incoming
public = yes
browseable = yes
only guest = yes
vfs objects = full_audit
full_audit:prefix = %u|%I
full_audit:failure = none
full_audit:success = connect disconnect opendir mkdir rmdir closedir open close read pread write pwrite sendfile rename unlink chmod fchmod chown fchown chdir ftruncate lock symlink readlink link mknod realpath
full_audit:facility = local5
full_audit:priority = notice

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

...
Feb 23 18:13:31 kirill smbd_audit: nobody|192.168.4.2|connect|ok|incoming
Feb 23 18:13:32 kirill smbd_audit: nobody|192.168.4.2|chdir|ok|chdir|/home/samba/incoming
Feb 23 18:13:35 kirill smbd_audit: nobody|192.168.4.2|opendir|ok|.
Feb 23 18:13:35 kirill smbd_audit: nobody|192.168.4.2|closedir|ok|
Feb 23 18:13:35 kirill smbd_audit: nobody|192.168.4.2|opendir|ok|./
Feb 23 18:13:48 kirill smbd_audit: nobody|192.168.4.2|opendir|ok|New Folder
Feb 23 18:13:48 kirill smbd_audit: nobody|192.168.4.2|closedir|ok|
Feb 23 18:13:48 kirill smbd_audit: nobody|192.168.4.2|rmdir|ok|New Folder
Feb 24 11:45:10 kirill smbd_audit: root|192.168.4.2|disconnect|ok|incoming
Feb 24 11:45:10 kirill smbd_audit: root|192.168.4.2|chdir|ok|chdir|/
...


7. Дополнительные настройки
Далее может понадобиться дополнительная настройка демонов syslogd и logrotate.
(Прим. В данном примере используются sysklogd 1.4.1 и logrotate 3.7.1)
7.1 В стандартном файле конфигурации syslog.conf демона syslogd имеется строка

*.*;auth,authpriv.none -/var/log/syslog

для того чтобы сообщения модуля full_audit не попадали в syslog, нужно изменить эту строку следующим образом:

*.*;local5,auth,authpriv.none -/var/log/syslog

Чтобы сообщения записывались в заданный файл, нужно добавить в syslog.conf такую строку:

local5.notice -/var/log/samba/log.audit

7.2 Для того чтобы лог-файл не разрастался, в каталоге /etc/logrotate.d можно изменить соответсвующую секцию конфигурационного файла samba, чтобы она выглядела примерно так:

/var/log/samba/log.smbd /var/log/samba/log.audit {
weekly
missingok
rotate 7
postrotate
invoke-rc.d --quiet samba reload > /dev/null
endscript
compress
notifempty
}