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" будут восприняты одинаково хорошо.

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

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
Неслабо так! Чувствую, всё равно придется донастраивать ему клиента, чтобы не хранить такие объемы на своем сервере.

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

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