не то, чтобы реальное уменьшение, но описан метод как избежать его бесконтрольного роста
http://vdachev.net/2007/02/22/mysql-reducing-ibdata1/
http://vdachev.net/2007/02/22/mysql-reducing-ibdata1/
четверг, 13 ноября 2014 г.
среда, 12 ноября 2014 г.
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, причем прямой связи между ними нет:
keywords: ACCOUNTINFO, ACCOUNTINFO_CONFIG, FIELDS_###
Я долго бился над одной совершенно дурацкой проблемой: в OCS Inventory версий 1.х таблица с дополнительной "административной" информацией была одна - ACCOUNTINFO - и имела довольно простой формат: каждый столбец таблицы представлял собой одно поле административной информации и делать выборку было не просто, а очень просто.
В версиях 2.х это изменилось: теперь все добавленные пользователем поля имеют имена вида FIELDS_XXX, где XXX - какое-то число, соответствующее порядковому номеру, каким по счёту добавлялось это поле. Описания же полей хранятся в таблице ACCOUNTINFO_CONFIG, причем прямой связи между ними нет:
среда, 29 октября 2014 г.
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 же говорит, что есть?
Гм... точно нету. Лезу на другой сервер:
И откуда оно?
Вернулся на обновленный:
Ну и кто ты после этого? На фига было сносить эту библиотеку?
Обновил сегодня на одном из серверов убунту с 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) …
Ну и кто ты после этого? На фига было сносить эту библиотеку?
четверг, 23 октября 2014 г.
От частного к общему или наоборот?
Писал сегодня 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 не появляется в смешанном поле.
Моя ошибка была в том, что я пошел от общего к частному, тогда как надо было идти наоборот. Перечислил частные случаи, комбинации производителей и моделей, до общих и всё заработало.
Мораль: проверяй условия от частного - к общему! И только так.
И надо мне обработать собранные данные (OCS Inventory по-прежнему рулит) для формирования одного отчета. Приходится анализировать содержимое полей на наличие ахинеи и в особо тяжелых случаях заменять ересь на что-то вроде "вписать вручную".
Вот и сейчас как раз допиливал кусок, отвечающий за разборку этих данных. Если производитель или модель - ахинея, то заменяю их для простоты дальнейшей обработки словом "NO".
И при составлении смешанного поля "модель-производителя" анализирую комбинации типа "если производитель NO и модель NO то "ввести вручную"", "если NO и не NO, то скомпоновать так-то" ну и т.д. Всего 4 комбинации.
Анализ случаев с особо трудными производителями (тот же Kraftway: mfg:"AWARD_", mdl:"MS-7676") вставил после этой проверки и долго не мог понять, почему же, несмотря на правильность регекспа, пресловутая материнка от MSI не появляется в смешанном поле.
Моя ошибка была в том, что я пошел от общего к частному, тогда как надо было идти наоборот. Перечислил частные случаи, комбинации производителей и моделей, до общих и всё заработало.
Мораль: проверяй условия от частного - к общему! И только так.
среда, 22 октября 2014 г.
SED: приводим в порядок дампы зон DNS
Понадобилось мне примерно такое вот привести в машинно-обрабатываемый вид. То есть, провести предварительную подготовку данных - выбрать только информацию об адресах
Ну, как известно, командная строка в линуксах рулит. Пропускаем этот дамп через такой фильтр:
(900 и 1200 - это два вида TTL, встречающихся в этих дампах, не стал вспоминать регекспы, а тупо сделал одну замену за другой)
Получаем на выходе красоту:
Дальше вставляю полученное в open/libre-office, который видит, что вставляемое очень похоже на табулированные данные и предлагает вставить их как CSV. Разумеется, я не против, только указываю, что столбцы отделяются пробелами...
Что и требовалось доказать:
Попытка вставить подобное в excel 2003 приводит к тому, что вместо трех столбцов получаем только один, и никаких параметров, позволяющих настроить вставку нет: есть только "текст юникод" и "текст". Возможно, в более поздних версиях MSO появилось такое, но не факт.
Дамп прямой зоны обрабатываем похожим фильтром:
Добавился еще один TTL и из этой зоны нас не интересуют адреса из подсетей 172.21.120.0/24 и 172.21.121.0/24
Получаем:
Ну красота же?
; 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
Ну красота же?
пятница, 17 октября 2014 г.
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, который выводит ключевые поля в виде привычных равномерных дампов.
Под катом текст еще не законченного скрипта, обрабатывающего это безобразие. Скрипт состоит в основном из комментариев, поскольку я не хочу забыть, почему я принял то или иное решение в ходе его написания. Да и заветы Чарльза Уэзерелла я помню...
Всё бы ничего, но вот в этом самом файле хранятся не имена файлов, к которым применены допольнительные ACL, а номера их inode. Естественно, в этом случае перенос tdb на другую машину ничего не даст: номера инодов будут гарантированно отличаться и получится каша.
В Netware была дополнительная утилита, которая делала полезную вещь - проходила по дереву каталогов от заданной точки и сбрасывала в файл назначенные каждому файлу и каталогу полномочия. В итоге, даже при полной потере этих дополнительных атрибутов можно было восстановить права на всё.
Ни в самбе, ни в Windows я подобного не нашел. Пришлось думать, как же достать полномочия. Изначально планировалось сделать дамп tdb и анализировать его, но дамп выводился в очень хитрой форме: символы с кодами <32 и >127 выводились в виде стандартных escape-последовательностей, тогда как обычные ASCII-символы выводились в своем символьном представлении. Что-то вроде \0x10Abc-\0x90: "Abc-" - это четыре символа. Быстро сделать парсинг такой смешанной строки средствами оболочки не получилось.
Тогда я понял, что, скорее всего, копаю не в ту сторону. Спасибо Олегу Адианову, чьё возмущение "неправильной постановкой задачи" по парсингу "хитрой строки" натолкнуло меня на мысль попробовать что-то другое.
Этим другим оказалась штатная утилита tdbtool из поставки самбы. У нее есть очень полезный параметр hexkeys, который выводит ключевые поля в виде привычных равномерных дампов.
Под катом текст еще не законченного скрипта, обрабатывающего это безобразие. Скрипт состоит в основном из комментариев, поскольку я не хочу забыть, почему я принял то или иное решение в ходе его написания. Да и заветы Чарльза Уэзерелла я помню...
MySQL: убрать лишние столбцы из результатов, возвращаемых запросом
Вещь вполне штатная, хотя и не очевидная.
Есть скрипт, читающий сложную базу и формирующий на основе ее данных довольно широкую таблицу. Из-за особенностей SQL, в выдачу попадают не только "полезные" столбцы, но и всякие служебные, которые используются для формирования "полезных". Например, в нескольких "полезных" столбцах используются результаты одного и того же суб-запроса. Можно, конечно, воткнуть этот субзапрос несколько раз в нужных местах, но тогда при каждом его изменении придется выискивать все эти места и в каждое вносить правку. Чем это чревато, знает любой программист. Создавать хранимую процедуру тоже неудобно по техническим причинам. Остается присвоить результаты суб-запроса @-переменной и уже ее использовать везде, где нужен этот результат.
При этом, однако, сама @-переменная будет представлена в выводе в виде отдельного столбца. Ему можно присвоить пустое имя, но в выводе он всё равно будет. А зачем?
Решение лежит на поверхности, но до меня оно дошло только тогда, когда в OpenOffice я попробовал сделать запрос, использующий в качестве источника данных другой запрос. Спасибо Евгению Корейбе, который подкинул идею использовать скрипт-"обёртку"
Итак, всё очень просто: пишем скрипт-"обёртку" типа:
select нужные_поля from (наш_чрезмерно_информативный_скрипт)
Как именно подсунуть чрезмерно информативного (ЧИС) - это уже детали. В конце концов можно его тупо скопипастить внутрь текста "обёртки". При любом способе, "обёртка" будет возвращать только нужное подмножество данных и ошибка может вылезти только тогда, когда в "нужных_полях" окажется поле, которое ЧИС больше не возвращает. Все остальные ошибки ищем в тексте самого ЧИС.
Чего я не проверял, так это насколько глубоко можно вкладывать селекты.
Есть скрипт, читающий сложную базу и формирующий на основе ее данных довольно широкую таблицу. Из-за особенностей SQL, в выдачу попадают не только "полезные" столбцы, но и всякие служебные, которые используются для формирования "полезных". Например, в нескольких "полезных" столбцах используются результаты одного и того же суб-запроса. Можно, конечно, воткнуть этот субзапрос несколько раз в нужных местах, но тогда при каждом его изменении придется выискивать все эти места и в каждое вносить правку. Чем это чревато, знает любой программист. Создавать хранимую процедуру тоже неудобно по техническим причинам. Остается присвоить результаты суб-запроса @-переменной и уже ее использовать везде, где нужен этот результат.
При этом, однако, сама @-переменная будет представлена в выводе в виде отдельного столбца. Ему можно присвоить пустое имя, но в выводе он всё равно будет. А зачем?
Решение лежит на поверхности, но до меня оно дошло только тогда, когда в OpenOffice я попробовал сделать запрос, использующий в качестве источника данных другой запрос. Спасибо Евгению Корейбе, который подкинул идею использовать скрипт-"обёртку"
Итак, всё очень просто: пишем скрипт-"обёртку" типа:
select нужные_поля from (наш_чрезмерно_информативный_скрипт)
Как именно подсунуть чрезмерно информативного (ЧИС) - это уже детали. В конце концов можно его тупо скопипастить внутрь текста "обёртки". При любом способе, "обёртка" будет возвращать только нужное подмножество данных и ошибка может вылезти только тогда, когда в "нужных_полях" окажется поле, которое ЧИС больше не возвращает. Все остальные ошибки ищем в тексте самого ЧИС.
Чего я не проверял, так это насколько глубоко можно вкладывать селекты.
Подписаться на:
Сообщения (Atom)
