RSYNC: как читать результаты --itemize-changes

С ключом -i (--itemize-changes) rsync выводит перечень проделанных изменений в виде:

~ $ rsync src/ dest/ -ai
.d..t.... ./
>f+++++++ newfile
>f..t.... oldfil

Интересно, но непонятно. Кто-то постарался и покурив маны создал вот такую схему, что есть что в выводе rsync. Разумеется, любой из нас может сделать то же самое, но почему-то никто не сделал. :-)

I wrote this little schema that helped me to understand this output format and I'm publishing hoping it will be useful for others.

YXcstpoguax  путь/к/файлу
|||||||||||
`----------- тип проделанных изменений:
 ||||||||||   <: файл был передан на удаленный узел (отправка).
 ||||||||||   >: файл был передан на локальный узел (приём).
 ||||||||||   c: локальное создание/изменение, например:
 ||||||||||      - создан каталог
 ||||||||||      - изменился симлинк,
 ||||||||||      - и т.д.
 ||||||||||   h: элемент суть жесткая ссылка на другой элемент (требуется --hard-links).
 ||||||||||   .: файл не обновлен (хотя некоторые его атрибуты могли измениться).
 ||||||||||   *: means that the rest of the itemized-output area contains a message (e.g. "deleting").
 ||||||||||
 `---------- тип файла:
  |||||||||   f файл,
  |||||||||   d каталог,
  |||||||||   L симлинк (symlink),
  |||||||||   D устройство (device),
  |||||||||   S специальный файл (например, сокет).
  |||||||||
  `--------- c: изменилась контрольная сумма (для обычных файлов)
   ||||||||     изменилось содержимое (для симлинков, устройств и специальных файлов)
   `-------- s: отличается размер
    `------- t: отличается время последнего изменения
     `------ p: изменились права доступа
      `----- o: изменился владелец
       `---- g: изменилась группа
        `--- u: (резерв на будущее)
         `-- a: изменилась информация в ACL

This schema is based on the contents of the rsync manual.
Наводку на схему получил здесь

MS IE: Автоматическое определение параметров и GPO: часть 2

Написал я предыдущий пост, показал его коллегам и один из них обозвал меня и автора скрипта дураком. Вот уж и не знаю, справедливо или нет.

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

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings
AutoDetect

Но этого ключа не видно в указанном пути. Почему? Да потому, что это "волатильный" ключ, который удаляется, как только IE обработал его значение.

Если работаем однонаправленно - принудительно задаем значение этого ключа, не интересуясь существующей настройкой, тогда однозначно прав мой коллега: дешевле получится через политики импортировать значение именно для ключа AutoDetect.

Но если возникает необходимость узнать о состоянии "автоматического определения", то сделать это чтением ключа AutoDetect можно только до первого запуска IE текущим пользователем в текущем сеансе, да и то не факт, что до этого момента какая-нибудь программа не дёрнет API IE для своих нужд, что так же приведет к удалению ключа.

В общем, решайте сами: если только на запись, то импортируйте ключ с нужным значением, если на запись и чтение - правьте бит в байте.

MS IE: Автоматическое определение параметров и GPO

Для старых версий Internet Explorer в оснастке групповых политик существовал раздел IE Maintenance. Но в более новых версиях контроллеров и для IE версий 10+ этого раздела нет, а сохранившиеся настройки не работают или работают частично.
Особую головную боль вызывает галочка "Автоматическое определение параметров", которая никак через политики не настраивается:

Samba: unable to initialize idmapping plugin

Пробуем в новой самбе посмотреть атрибуты файла

# getcifsacl какой-то-файл-где-то-там
WARNING: unable to initialize idmapping plugin: /etc/cifs-utils/idmap-plugin: cannot open shared object file: No such file or directory
REVISION:0x1
CONTROL:0x9004
OWNER:S-1-5-21-587157376-4245349843-3568593853-22618
GROUP:S-1-5-21-587157376-4245349843-3568593853-513
ACL:S-1-5-21-587157376-4245349843-3568593853-22618:ALLOWED/0x0/0x1e01ff
ACL:S-1-5-21-587157376-4245349843-3568593853-513:ALLOWED/0x0/0x1e01ff
ACL:S-1-5-21-587157376-4245349843-3568593853-513:ALLOWED/0x0/0x1e01ff
ACL:S-1-5-21-587157376-4245349843-3568593853-22618:ALLOWED/0x0/0x1e01ff
ACL:S-1-1-0:ALLOWED/0x0/R

Хреново. Почему это какой-то плагин не инициализирован? Ответ здесь в параграфе "Packaging Bugs": в некоторых дистрибутивах пакеты идут недоделанные, без некоторых симлинков. Лечение для убунты (по ссылке выше есть и для Арча):

# Ubuntu 14, cifs-utils 2:6.0-1ubuntu2
mkdir /etc/cifs-utils
ln -s /usr/lib/x86_64-linux-gnu/cifs-utils/idmapwb.so /etc/cifs-utils/idmap-plugin

Либо, в случае 32-битной:

# Ubuntu 14, cifs-utils 2:6.0-1ubuntu2
mkdir /etc/cifs-utils
ln -s /usr/lib/i386-linux-gnu/cifs-utils/idmapwb.so /etc/cifs-utils/idmap-plugin

OCS-NG Inventory 2.x: продолжаем миграцию. Параметры подсетей.

Посредством лома и какой-то матери перенес данные из таблиц версии 1.х в таблицы версии 2.х. После удаления созданной по шаблону accountinfo_config, нормально отработала конверсия старых данных accountinfo в новый формат (вот и пригодится рассмотренный чуть ранее view).
Пошел проверять настройки подсетей, вроде всё выглядит гладко:



Однако... Однако при проверке вылезло:


вот те раз! А где ж ID 120000, который прекрасно виден в предыдущей таблице? А нету!

MySQL: уменьшение размера ibdata1

не то, чтобы реальное уменьшение, но описан метод как избежать его бесконтрольного роста

http://vdachev.net/2007/02/22/mysql-reducing-ibdata1/

OCS-NG Inventory 2.x: нормальный доступ к новому формату ACCOUNTINFO

abstract: convenient human-readable access to ACCOUNTINFO table from OCS-NG Inventory 2.x
keywords: ACCOUNTINFO, ACCOUNTINFO_CONFIG, FIELDS_###

Я долго бился над одной совершенно дурацкой проблемой: в OCS Inventory версий 1.х таблица с дополнительной "административной" информацией была одна - ACCOUNTINFO - и имела довольно простой формат: каждый столбец таблицы представлял собой одно поле административной информации и делать выборку было не просто, а очень просто.
В версиях 2.х это изменилось: теперь все добавленные пользователем поля имеют имена вида FIELDS_XXX, где XXX - какое-то число, соответствующее порядковому номеру, каким по счёту добавлялось это поле. Описания же полей хранятся в таблице ACCOUNTINFO_CONFIG, причем прямой связи между ними нет: