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, причем прямой связи между ними нет:

SAMBA: libnss-winbind при обновлении

Абстракт: после обновления ubuntu пользователи самбы потеряли доступ к шарам.

Обновил сегодня на одном из серверов убунту с 12.04 до 14.04.1
В целом обновилось нормально, но вылезла совершенно неожиданная грабля, о которой я и не подумал: настройки в /etc/nsswitch.conf сохранились, wbinfo работает отлично, но авторизация пользователей не проходит: check_ntlm_password:  Authentication for user FAILED with error NT_STATUS_NO_SUCH_USER, и всё тут!
Скопировал было содержимое /etc/pam.d с другого сервера, на который изначально ставилась 14.04 - чуть не остался без доступа в систему, благо, что специально открыл 2 ssh сессии, одну из которых - под рутом. Удалось вернуть всё на место.
Вроде перепробовал все варианты, ничего не помогает. В одном из нагугленных сайтов кто-то упоминал /lib/.../libnss_winbind.so
Дай-ка, думаю, проверю...

$ locate nss_winbind
/lib/x86_64-linux-gnu/libnss_winbind.so.2
/usr/share/doc/samba-doc/examples/nss/nss_winbind.c.gz
/usr/share/doc/samba-doc/examples/nss/nss_winbind.h

Вроде всё путём, однако...

$ ls /lib/x86_64-linux-gnu/libnss_winbind*
ls: cannot access /lib/x86_64-linux-gnu/libnss_winbind*: No such file or directory

То есть, как это - нету такого файла? Locate же говорит, что есть?

$ ls /lib/x86_64-linux-gnu/libnss_*
/lib/x86_64-linux-gnu/libnss_compat-2.19.so  /lib/x86_64-linux-gnu/libnss_files-2.19.so   /lib/x86_64-linux-gnu/libnss_nis-2.19.so
/lib/x86_64-linux-gnu/libnss_compat.so.2     /lib/x86_64-linux-gnu/libnss_files.so.2      /lib/x86_64-linux-gnu/libnss_nisplus-2.19.so
/lib/x86_64-linux-gnu/libnss_dns-2.19.so     /lib/x86_64-linux-gnu/libnss_hesiod-2.19.so  /lib/x86_64-linux-gnu/libnss_nisplus.so.2
/lib/x86_64-linux-gnu/libnss_dns.so.2        /lib/x86_64-linux-gnu/libnss_hesiod.so.2     /lib/x86_64-linux-gnu/libnss_nis.so.2

Гм... точно нету. Лезу на другой сервер:

$ ls -la /lib/x86_64-linux-gnu/libnss_winbind*
lrwxrwxrwx 1 root root    19 июля   9 06:39 /lib/x86_64-linux-gnu/libnss_winbind.so -> libnss_winbind.so.2
-rw-r--r-- 1 root root 18592 авг.   2 09:37 /lib/x86_64-linux-gnu/libnss_winbind.so.2

И откуда оно?

$ sudo dpkg -S libnss_winbind
Password: 
libnss-winbind:amd64: /lib/x86_64-linux-gnu/libnss_winbind.so.2

Вернулся на обновленный:

# apt-get install libnss-winbind
Чтение списков пакетов… Готово
Построение дерева зависимостей       
Чтение информации о состоянии… Готово
НОВЫЕ пакеты, которые будут установлены:
  libnss-winbind
обновлено 0, установлено 1 новых пакетов, для удаления отмечено 0 пакетов, и 7 пакетов не обновлено.
Необходимо скачать 12,3 kБ архивов.
После данной операции, объём занятого дискового пространства возрастёт на 167 kB.
Получено:1 http://ru.archive.ubuntu.com/ubuntu/ trusty-updates/universe libnss-winbind amd64 2:4.1.6+dfsg-1ubuntu2.14.04.3 [12,3 kB]
Получено 12,3 kБ за 0с (42,2 kБ/c)       
Выбор ранее не выбранного пакета libnss-winbind:amd64.
(Чтение базы данных … на данный момент установлено 95309 файлов и каталогов.)
Preparing to unpack …/libnss-winbind_2%3a4.1.6+dfsg-1ubuntu2.14.04.3_amd64.deb ...
Unpacking libnss-winbind:amd64 (2:4.1.6+dfsg-1ubuntu2.14.04.3) ...
Настраивается пакет libnss-winbind:amd64 (2:4.1.6+dfsg-1ubuntu2.14.04.3) …

Ну и кто ты после этого? На фига было сносить эту библиотеку?

От частного к общему или наоборот?

Писал сегодня SQL-запрос. Надо среди прочего выбрать из базы инвентаризации производителя и модель материнки. Надо сказать, что в этом деле у производителей полный разнобой. Кто-то оставляет эти поля незаполненными - "to be filled by OEM" или "system name/system manufacturer", другие, как например HP, вместо модели материнки вписывают модель самого компа, российский Kraftway в половине машин пишет, что производитель - Kraftway, а материнка - GEG, а в другой половине (та же модель!), что материнка - MSI-такая-то. Но в обоих случаях компы собраны на одной и той же материнке.

И надо мне обработать собранные данные (OCS Inventory по-прежнему рулит) для формирования одного отчета. Приходится анализировать содержимое полей на наличие ахинеи и в особо тяжелых случаях заменять ересь на что-то вроде "вписать вручную".

Вот и сейчас как раз допиливал кусок, отвечающий за разборку этих данных. Если производитель или модель - ахинея, то заменяю их для простоты дальнейшей обработки словом "NO".
И при составлении смешанного поля "модель-производителя" анализирую комбинации типа "если производитель NO и модель NO то "ввести вручную"", "если NO и не NO, то скомпоновать так-то" ну и т.д. Всего 4 комбинации.
Анализ случаев с особо трудными производителями (тот же Kraftway: mfg:"AWARD_", mdl:"MS-7676") вставил после этой проверки и долго не мог понять, почему же, несмотря на правильность регекспа, пресловутая материнка от MSI не появляется в смешанном поле.

Моя ошибка была в том, что я пошел от общего к частному, тогда как надо было идти наоборот. Перечислил частные случаи, комбинации производителей и моделей, до общих и всё заработало.

Мораль: проверяй условия от частного - к общему! И только так.

SED: приводим в порядок дампы зон DNS

Понадобилось мне примерно такое вот привести в машинно-обрабатываемый вид. То есть, провести предварительную подготовку данных - выбрать только информацию об адресах

;  Database file (null) for 127.21.172.in-addr.arpa zone.
;      Zone version:  180
;
@                       IN  SOA cnt10srv031.contoso.com. hostmaster.contoso.com. (
                                180          ; serial number
                                28800        ; refresh
                                7200         ; retry
                                604800       ; expire
                                3600       ) ; default TTL
;
;  Zone NS records
;
@                       NS    cnt10srv030.contoso.com.
@                       NS    cnt30srv030.contoso.com.
;
;  Zone records
;
1                       PTR    cnt30nce017.contoso.com.
152                     PTR    cnt30nce202.contoso.com.
158                     PTR    cnt30prn044.contoso.com.
68                      PTR    cnt30nce907.contoso.com.
85                      [AGE:3627316]    1200    PTR    cnt301512.contoso.com.
87                      [AGE:3627293]    1200    PTR    cnt301561.contoso.com.
90                      PTR    cnt30prn025.contoso.com.

Ну, как известно, командная строка в линуксах рулит. Пропускаем этот дамп через такой фильтр:

cat имя_дампа|grep PTR|sed -e 's/  */ /g;s/\[.*\]//;s/\t/ /g;s/ 1200 //g;s/ 900 //g'

(900 и 1200 - это два вида TTL, встречающихся в этих дампах, не стал вспоминать регекспы, а тупо сделал одну замену за другой)

Получаем на выходе красоту:

1 PTR cnt30nce017.contoso.com.
152 PTR cnt30nce202.contoso.com.
158 PTR cnt30prn044.contoso.com.
68 PTR cnt30nce907.contoso.com.
85 PTR cnt301512.contoso.com.
87 PTR cnt301561.contoso.com.
90 PTR cnt30prn025.contoso.com.

Дальше вставляю полученное в open/libre-office, который видит, что вставляемое очень похоже на табулированные данные и предлагает вставить их как CSV. Разумеется, я не против, только указываю, что столбцы отделяются пробелами...




Что и требовалось доказать:



Попытка вставить подобное в excel 2003 приводит к тому, что вместо трех столбцов получаем только один, и никаких параметров, позволяющих настроить вставку нет: есть только "текст юникод" и "текст". Возможно, в более поздних версиях MSO появилось такое, но не факт.

Дамп прямой зоны обрабатываем похожим фильтром:

grep -v -E ".21.120|.21.121|CNAME" имя_дампа|sed -e 's/  */ /g;s/\[.*\]//;s/\t/ /g;s/ 1200 / /g;s/ 900 / /g;s/ 600 / /g;s/  / /g'

Добавился еще один TTL и из этой зоны нас не интересуют адреса из подсетей 172.21.120.0/24 и 172.21.121.0/24

Получаем:

cnt30srv030 A 172.21.122.212
cnt30SRV041 A 172.21.122.135
cnt30SRV951 A 172.21.122.160

Ну красота же?