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

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

SMBCACLS: выдергивание данных из file_ntacls.tdb

В перспективе светит задача переноса данных с одного сервера на другой. Поскольку штатных полномочий доступа в никсах недостаточно для тонкой настройки доступа к файлам на самбе, пришлось воспользоваться дополнительным модулем, который хранит расширенные полномочия в /var/cache/samba/file_ntacls.tdb.
Всё бы ничего, но вот в этом самом файле хранятся не имена файлов, к которым применены допольнительные ACL, а номера их inode. Естественно, в этом случае перенос tdb на другую машину ничего не даст: номера инодов будут гарантированно отличаться и получится каша.

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

Ни в самбе, ни в Windows я подобного не нашел. Пришлось думать, как же достать полномочия. Изначально планировалось сделать дамп tdb и анализировать его, но дамп выводился в очень хитрой форме: символы с кодами <32 и >127 выводились в виде стандартных escape-последовательностей, тогда как обычные ASCII-символы выводились в своем символьном представлении. Что-то вроде \0x10Abc-\0x90: "Abc-" - это четыре символа. Быстро сделать парсинг такой смешанной строки средствами оболочки не получилось.
Тогда я понял, что, скорее всего, копаю не в ту сторону. Спасибо Олегу Адианову, чьё возмущение "неправильной постановкой задачи" по парсингу "хитрой строки" натолкнуло меня на мысль попробовать что-то другое.

Этим другим оказалась штатная утилита tdbtool из поставки самбы. У нее есть очень полезный параметр hexkeys, который выводит ключевые поля в виде привычных равномерных дампов.

Под катом текст еще не законченного скрипта, обрабатывающего это безобразие. Скрипт состоит в основном из комментариев, поскольку я не хочу забыть, почему я принял то или иное решение в ходе его написания. Да и заветы Чарльза Уэзерелла я помню...

MySQL: убрать лишние столбцы из результатов, возвращаемых запросом

Вещь вполне штатная, хотя и не очевидная.

Есть скрипт, читающий сложную базу и формирующий на основе ее данных довольно широкую таблицу. Из-за особенностей SQL, в выдачу попадают не только "полезные" столбцы, но и всякие служебные, которые используются для формирования "полезных". Например, в нескольких "полезных" столбцах используются результаты одного и того же суб-запроса. Можно, конечно, воткнуть этот субзапрос несколько раз в нужных местах, но тогда при каждом его изменении придется выискивать все эти места и в каждое вносить правку. Чем это чревато, знает любой программист. Создавать хранимую процедуру тоже неудобно по техническим причинам. Остается присвоить результаты суб-запроса @-переменной и уже ее использовать везде, где нужен этот результат.
При этом, однако, сама @-переменная будет представлена в выводе в виде отдельного столбца. Ему можно присвоить пустое имя, но в выводе он всё равно будет. А зачем?

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

Итак, всё очень просто: пишем скрипт-"обёртку" типа:

select нужные_поля from (наш_чрезмерно_информативный_скрипт)

Как именно подсунуть чрезмерно информативного (ЧИС) - это уже детали. В конце концов можно его тупо скопипастить внутрь текста "обёртки". При любом способе, "обёртка" будет возвращать только нужное подмножество данных и ошибка может вылезти только тогда, когда в "нужных_полях" окажется поле, которое ЧИС больше не возвращает. Все остальные ошибки ищем в тексте самого ЧИС.

Чего я не проверял, так это насколько глубоко можно вкладывать селекты.