December 9th, 2012

404

О классификации дистопии

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

Если с первым всё более-менее понятно, случилась беда, выживаем как можем, то второе - это очень сложная и тонкая тема.

Сложная она потому, что оценка "дистопия или нет" определяется совершенно случайными факторами точки зрения автора, читателя/зрителя, положением главного героя и т.д. Более того, вполне почтенным жанром считается жанр IRL дистопии, когда берут и показывают, что вот конкретному Имяреку-то в нашем мире живётся плохо.

Куда хуже становится, когда такую оценку перетаскивают в окружающий мир. ...Раз и мы видим отчаянно страдающую зелёную-аутистку, созерцающую кошмары лесоповала и растаптывание цветочков.

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

Ну и существует модификация, на мой взгляд, самая глупая, это когда берут некий сеттинг (цубепунк, альтернативную историю или ещё что-то), более-менее терпимую, и добавляют туда Омерзительную Вещь.

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

Или мирное общество, в котором для поддержания порядка 2% людей надо зверски замучивать насмерть. Или ещё что-то подобного габарита нелепицы.

Ключевым фактором таких "наносных дистопий" является абсурдное криптозлодейство. В "brave new world" антиутопия не была скрытой, она была основной мира, и антиутопия заключалась в том, что всех это устраивало (и в какой-то момент звучала интонация, что не такая уж это и антиутопия).

Собственно, к чему я? Слишком много наносной дистопии в shin sekai yori. Слишком много искусственно уродливого, совсем не к месту и не по делу.

Если нам не предложат какого-то хорошего объяснения, то выглядеть оно будет страшненько и уродливенько.
404

wacom && dual monitor configuration (XFCE)

Last piece of xfce comfort environment - Set up wacom to draw only for one monitor.

Dual configuration with xrandr support. If xrandr is not supported (f.e. binary nvidia) this method would not work.

1) Get list of active outputs:

$ xrandr

should looks like this:

Screen 0: minimum 320 x 200, current 5392 x 1440, maximum 8192 x 8192
DVI-I-1 connected 2560x1440+0+0 (normal left inverted right x axis y axis) 597mm x 336mm
2560x1440 60.0*+
(skip)
640x350 85.1
DVI-I-2 connected 2560x1440+2832+0 (normal left inverted right x axis y axis) 597mm x 336mm
2560x1440 60.0*+
(skip)
640x350 85.1

DVI-I-1/DVI-I-2 is output names.

Next: get list of wacom devices:

$ xsetwacom --list
Wacom Bamboo Connect Pen stylus id: 12 type: STYLUS
Wacom Bamboo Connect Pen eraser id: 13 type: ERASER
Wacom Bamboo Connect Finger touch id: 14 type: TOUCH
Wacom Bamboo Connect Finger pad id: 15 type: PAD



Next: Limit input to single monitor:

$ xsetwacom set "Wacom Bamboo Connect Pen stylus" MapToOutput DVI-I-2


Option MapToOutput works only with xrandr.

Details here: http://sourceforge.net/apps/mediawiki/linuxwacom/index.php?title=Dual_and_Multi-Monitor_Set_Up#MapToOutput
404

XCP/OVS hack

Т.к. в XCP 1.6 появился антиспуфинг из коробки (он настолько facepalm, что словами не описать), то я решил жёсткие правила переписать с патча на scripts/vif во внутрь скрипта, накладывающего эти правила. К счастью, в этом месте у нас будут все нужные данные в xenstore, так что процесс будет совершенно автономным от базы данных.

Проблема в том, что жёсткие правила подразумевают * * * * * * * action=drop в самом конце списка. Писать их в основные правила глупо (70 виртуалок = 70 строк drop).

Возникает желание засунуть их в процесс конфигурирования интерфейса. Пока что нашёл вот это:

InterfaceReconfigureVswitch.py, функция configure_datapath.

Цитата:

Returns a tuple containing
- A list containing the necessary vsctl command line arguments
- A list of additional devices which should be brought up after
the configuration is applied.
- A list containing flows to apply to the pif bridge, note that
port numbers may need to be substituted once ofport is known

Отсюда мысль: поиграться с третьим пунктом. Переменная называется bridge_flows.

Ключевая проблема: я хочу в этом месте различать management-интерфейс от пользовательского. Обычно это делается либо метками в базе данных, либо (как аварийный вариант) через /etc/xensource-inventory.

Перфектным вариантом было бы использование locking-mode из свойств объекта network в базе XCP, но у меня ощущение, что до него тут не достучаться. Сейчас я посмотрю, что у нас в xenstore доступно на момент конфигурации...

... С другой стороны народ в тексте во всю дёргает базу данных на тему кому какой пиф чем приходится.

А network, а network???

Внезапно:

network = db().get_network_by_bridge(bridge)

Итого, нам надо придумать, куда писать режим особой блокировки.

Вот что у нас в ассортименте:

             name-label ( RW): Pool-wide network associated with eth1
        name-description ( RW): 
               VIF-uuids (SRO): 
               PIF-uuids (SRO): 12cf941e-97ef-a67e-2f18-6ffb7862aa98; 2d83c436-a75a-a9f1-8da7-c0fb6bb08980
                     MTU ( RW): 1500
                  bridge ( RO): xenbr1
            other-config (MRW): 
                   blobs ( RO): 
                    tags (SRW): 
    default-locking-mode ( RW): unlocked


Причём для default-locking-mode есть варианты только unlocked или disabled. Вероятнее всего, в самом крутом режиме тут надо будет сделать что-то вроде enforced, но трогать xapi и xe ради этого не хочется. Так что мы будем abuse'ить как всегда other-config.

Точнее, вот два варианта:

1) Мы прописываем drop в дефолтный флоу для всех интерфейсов, кроме management'а (и берём его из /etc/xensource-inventory)
2) Мы прописываем для блокируемых "по-новому" network'ов в other-config опцию, например, direct-datapath:true.

К сожалению, мы не можем получить опции network в setup-vif-rules (там доступно только то, что скопировали для vif'а), так что патч в любом случае инвазивный. Ключевой момент тут в том, что если мы не прописываем финальный дроп, то наш патч мало отличается от банального action=normal (т.к. если мы не знаем адреса для интерфейса, то все наши правила просто пролетают мимо, и всё идёт к normal в финале).

Итак, финальная схема выглядит так:

1) enforce режим для сети выставляется в атрибутах network. Это защищает от шальных интерфейсов не в том network'е, глушащих management залётным drop'ом.
2) Мы вешаем наши "суровые" правила на unlocked. Звучит глупо, да. Но в дальнейшем можно будет сделать опцию enforced или ещё как-то, а главное, что патч ничего не ломает в существующем режиме, то есть его можно смело засылать как pull-реквест (заодно и проверим, насколько цитрикс опенсорснутый).


Ща я это всё пошаманю, проверю в бою, и если оно реально будет работать, коммитну в форкнутую версию xapi с xen-org'а на гитхабе.
404

xcp

Внезапно: /opt/xensource/libexec/interface-reconfigure, /opt/xensource/libexec/InterfaceReconfigureBridge.py и прочие - не вызываются вообще.

Я в большой задумчивости о том, каким хером в новом xcp создаются бриджи.

UPD: Кажется, моё светлое будущее рассыпается под ударами окамла. Кажется, всё конфигурирование происходит из network/network_server.ml (и егойный network_utils, который тупо дёргает ovs когда нужно).

Ну не хочу я теребить xapi! Совсем не хочу.

Остаётся менее приятный вариант с 'drop' прямо в setup-vif-rules (и проверкой, что это не management). Но такое явно в апстрим не зашлёшь... Увы.