Официальная возможность получить лицензионный софт бесплатно.
Giveaway of the Day
Это не реклама!

Щелкните для получения прогноза по Биробиджану


пятница, 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, который выводит ключевые поля в виде привычных равномерных дампов.

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

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

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

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

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

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

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

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

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

вторник, 30 сентября 2014 г.

SMBCACLS: практические примеры 2

Всё-таки, я разобрался, как можно ставить одной командой несколько разрешений. Надо внимательнее курить маны!
Для большей читаемости строку с ACL стоит сформировать в переменной, дабы не гадать, какие подстановки smbcacls сможет отработать, а какие нет.

    do_acl="ACL:Everyone:DENIED/0x0/D,ACL:$use_domain\\$owner_group:DENIED/0x0/D,ACL:creator group:DENIED/0x0/D,ACL:$use_domain\\Domain users:DENIED/0x0/DPO"
 
    smbcacls -a "$do_acl" //server[.FQDN]/$share_name $dir_name -U $use_domain\\$owner_name%$owner_password

имена переменных говорят сами за себя, у меня они определяются в начале скрипта или по ходу его выполнения. Переменную $do_acl берем в кавычки, поскольку в ней могут содержаться пробелы и другие неприятные символы, на которые smbcacls обижается.

Регистр в названиях стандартных псевдогрупп и псевдопользователей соблюдать не надо: "creator group" и "Creator Group" будут восприняты одинаково хорошо.

четверг, 25 сентября 2014 г.

SMBCACLS: практические примеры

Долго искал, но не мог найти ничего вразумительного по использованию утилиты, позволяющей из командной строки линукса управлять правами доступа к файлам на шарах.

NB! на своих серверах я не использую "default domain", поэтому имена доменных пользователей у меня всегда задаются в виде домен\\логин.

Простой просмотр прав (унаследованных и нет) на файл или папку в расшаренном ресурсе:


smbcacls //сервер[.FQDN]/ресурс файл|каталог -U домен\\пользователь

папка созданная рутом на самом сервере:

smbcacls //cnt30srv042.contoso.com/scan cnt30prn098 -U contoso\\gates_wh
Enter contoso\gates_wh's password:
REVISION:1
CONTROL:SR|DP
OWNER:Unix User\root
GROUP:CNT30SRV042\Domain Admins
ACL:Unix User\root:ALLOWED/0x0/FULL
ACL:CNT30SRV042\Domain Admins:ALLOWED/0x0/FULL
ACL:Everyone:ALLOWED/0x0/
ACL:Creator Owner:ALLOWED/OI|CI|IO/FULL
ACL:Creator Group:ALLOWED/OI|CI|IO/FULL
ACL:Everyone:ALLOWED/OI|CI|IO/READ

пятница, 5 сентября 2014 г.

Zimbra: переполнение почтовых ящиков

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

Пользователи работают через POP3, и в их Outlook-ax выставлено "Удалять сообщения с сервера через 14 дней". Разумное ограничение, ведь бывает, что пользователь скачал сообщение и случайно удалил его у себя в клиенте, и самый быстрый способ вернуть статус-кво - это залезть в п/я веб-клиентом. (вариант не единственный, но речь сейчас не об этом)

Квота задана COS-ом, 300МБ на ящик. Но одному из пользователей не хватает и этого. Делать ему отдельный COS или вручную править лимиты не хочется. В итоге, если не разрешить POP3 удалять сообщения с сервера сразу по получении, или не делать ручную чистку ящика, то переполнение наступает очень быстро и письма к этому пользователю зависают в очередях, регулярная проверка которых приводит к снижению производительности сервера со всеми неприятными вытекающими.

При просмотре параметров п/я обнаружился параметр, аналога которому в UI ZCS-OSE 8.0.6 я не нашел:

$ zmprov ga пользователь|grep Quota
zimbraMailAllowReceiveButNotSendWhenOverQuota: FALSE
zimbraMailQuota: 314572800
zimbraQuotaWarnInterval: 1d
zimbraQuotaWarnMessage: (текст предупреждения удален)
zimbraQuotaWarnPercent: 90

Вот это - zimbraMailAllowReceiveButNotSendWhenOverQuota - что? В UI не нашел, хотя, может, плохо искал. Однако, название параметра говорит само за себя: "разрешить получение, но не отправку при переполнении п/я". Что нам, собственно, и требуется, поскольку почта в очередях имеет привычку протухать.

Провел эксперимент:

$ zmmailbox -z -m gms трудный_пользователь
299.62 MB

Понятно, ящик забит под завязку.

$#ошибся первый раз:
$ zmprov ma трудный_пользователь zimbraMailAllowReceiveButNotSendWhenOverQuota=true
usage:  modifyAccount(ma) {name@domain|id} [attr1 value1 [attr2 value2...]]
For general help, type : zmprov --help

$#ошибся второй раз:
$ zmprov ma трудный_пользователь zimbraMailAllowReceiveButNotSendWhenOverQuota true
ERROR: account.INVALID_ATTR_VALUE (zimbraMailAllowReceiveButNotSendWhenOverQuota must be TRUE or FALSE)

$#а вот так правильно:
$ zmprov ma трудный_пользователь zimbraMailAllowReceiveButNotSendWhenOverQuota TRUE

То есть, с какого-то перепуга булев параметр стал чувствителен к регистру? Ну да ладно... Заходим в диспетчер очередей и видим, что бедного пользователя в очереди на протухание ждут 129 сообщений. Но мы ж вроде разрешили доставку в переполненный ящик? Делаем "сброс" - попытку доставить всю ожидающую почту. Как ни странно, но очередь очищается, значит почта доставлена. Что ж, снова посмотрим, что там с размером п/я:

$ zmmailbox -z -m gms трудный_пользователь
640.17 MB

Неслабо так! Чувствую, всё равно придется донастраивать ему клиента, чтобы не хранить такие объемы на своем сервере.

среда, 3 сентября 2014 г.

VMWare ESXi/VSphere: как остановить затянувшееся копирование

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

При всём удобстве GParted-a, он не умеет одну вещь, которую умеет Norton Ghost: он не умеет копировать разделы с уменьшением размера. То есть, если есть раздел размером 100 гигов и на нем занято только 5, то его нельзя GParted-ом скопировать на диск размером 50 гигов. И ладно, если бы это было ограничение файловой системы - 100 гигов ext4, например, мне не позволили ужать даже штатными средствами меньше чем, примерно, до 95.

Поэтому, чтобы не заниматься экстренным изучением других инструментов, создал на NFS аналогичный по размерам виртуальный диск и начал копировать туда раздел с существующего диска. Чёрт! Он собирается копировать 30+ гигов около 10 минут! Типа, очень долго, ага!

Решил, как умная Маша, скопировать целиком каталог этой виртуалки на сетевое хранилище. А что? Влёгкую! Открываем два браузера datastor-ов - местный и сетевой, copy/paste и вуаля! Вуаля? А хрен там! "Ожидаемое время копирования: 4 часа".

Не, ну меня это как-то не устраивает, причем совсем - у меня полчаса до окончания рабочего дня. Пытаюсь остановить копирование, но кнопка cancel не активна. Закрываю окошко копирования, но не помогает - в окне протокола вижу, что процесс продолжает идти своим ходом.

Перезагрузка гипервизора - не вариант, на нем крутятся еще несколько машин, которые нельзя просто так остановить. Что делать?

Решение нашлось здесь.

1. разрешаем административную консоль (подключение по SSH)
2. логинимся в нее
3a. (для ESX) перезапускаем клиентского демона

service mgmt-vmware restart
 
3b. (для Esxi) перезапускаем клиентского демона

/etc/init.d/hostd restart

Опосля ждем, пока клиент обнаружит, что потерял соединение и попробует переподключиться, либо просто закрываем клиента и запускаем его заново. Вот теперь вуаля!

суббота, 30 августа 2014 г.

Внешний выпуск "Биробиджанского Ведомасона"


(материал предоставлен внештатным корреспондентом ZEROC)
(первоисточник)


Cобраны неопровержимые доказательства вторжения Мордорской Федерации на территорию демократической Укроббитании.



Бронекавалерийская дивизия Черного Властелина захватила Новоазовск и Хоббитон и вышла к Мариуполю.