Zimbra 8: выбор между http и https для клиентского доступа

Был несколько удивлен, что для доступа к своим п/я пользователям теперь необходимо использовать https, без вариантов. Учитывая непреодолимую тупость пользователей, для которых предложение "измени закладку в избранном" звучит как "нарисуй мне принципиальную схему БАК", это надо либо писать для них очередную инструкцию с картинками на уровне букваря для первого класса школы для умственно отсталых, либо править все закладки самому. Ну, можно, конечно, воспользоваться политиками домена, но это не всегда возможно.
Хорошо, конечно, что веб-доступом у меня пользуются единицы, из которых только один постоянно, а остальные - эпизодически в особо трудных случаях.

Выход, однако, есть, причем штатными способами:

zmtlsctl

zmtlsctl [mode]

Mode Choices

• http - http only, the user would browse to http://zimbra.domain.com

• https - https only, the user would browse to https://zimbra.domain.com http:// is denied.

• both - A user can go to http:// or https:// and will keep that mode for their entire session.

• mixed - If the user goes to http:// it will switch to https:// for the login only, then will revert to http:// for normal session traffic. If they browse to https:// then they will stay https://

• redirect - Like mixed if the user goes to http:// it will switch to https:// but they will stay https:// for their entire session.

Note: Redirect mode is not available for ZCS 4.5 and earlier. (See Redirect_http_to_https for information about redirect for ZCS 4.5.)

Steps to run

1. Type zmtlsctl [mode] and press Enter.
2. Type zmcontrol stop and press Enter.
3. When everything is stopped, type zmcontrol start and press Enter. 

не совсем, правда, понятно, что этот zmtlsctl делает без параметров:

zimbra@host:~$ zmtlsctl 
Rewriting config files for cyrus-sasl, webxml and mailboxd...done.

ADDS: error 0x800704b8 не подключаются диски

Позвонил пользователь: не мапятся сетевые диски, которые раньше прекрасно мапились.
Стандартные виндовые журналы и gpupdate/force вкупе с gpresult/z ничего интересного не дали: есть event ID: 4098, есть код ошибки 0x800704b8, и есть офигенно полезное описание "ошибка расширенного типа".

Не трахая мозги: на компе пользователя часы убежали минут на 10 вперед, из-за чего файловые самба-серверы и контроллеры домена сильно расстроились.
Вылечилось командой

net time /domain:мой_домен /set /yes

Zimbra: перенос паролей пользователей

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

Более того, команда:

zmprov ga <account>

возвращает что-то вроде:

# name <account>
userPassword: VALUE-BLOCKED

что для нас совсем бесполезно. Однако, если команду слегка изменить и добавить "брать данные из LDAP", то картина меняется:

zmprov -l ga <account> userPassword
# name <account>
userPassword: {SSHA}ДлиннаяСтрокаАбракадабры

(-l - маленькая латинская L, а не i или единица!)

А вот это уже веселее. Получаю такой пароль для пользователя на старом сервере и пробую скормить его на новом:

zmprov ma <account> userPassword {SSHA}ДлиннаяСтрокаАбракадабры

zmprov молча глотает это безобразие и прекрасно пускает меня со старым паролем уже на новом сервере. Красота! Осталось вытащить со старого сервера старые пароли. Ну, на такие грабли наступал не я один, поэтому решение уже нашлось:

for i in `zmprov -l gaa | egrep -v 'galsync|spam|ham|virus|stimpson'`;do \
  echo "$i,`zmprov -l ga $i userPassword | grep userPassword | \
  sed 's/userPassword: //'`";\
done;

Стимпсон - это старое имя сервера того, кто придумал эту команду, поэтому его можно смело удалить. И я немного доработал вывод команды, чтобы она формировала мне готовый набор команд для пакетной обработки:

for i in `zmprov -l gaa | egrep -v 'avir|galsync|spam|ham|virus'`;do \
   echo "zmprov ma $i userPassword `zmprov -l ga $i userPassword | \ 
   grep userPassword | sed 's/userPassword: //'`"; \
done;

Перенаправить вывод этой команды в файл мне не удалось, но это и не важно - ее результаты я скопировал из терминала в файл, который и запустил, добавив шабанг в начале :-)

Zimbra: перенос алиасов

После переноса учеток не помешает перенести алиасы. Пошел таким неортодоксальным путём.

Нашел способ вывести список алиасов:

for i in `zmprov -l gaa`; do echo ""; echo "$i:"; zmprov ga $i | grep MailAlias; done >/opt/zimbra/log/aliases.txt

Но полученный файл содержит вперемешку как учетки, так и их алиасы:

admin@mydomain:
zimbraMailAlias: root@mydomain
zimbraMailAlias: postmaster@mydomain

wiki@mydomain:

spam.ro7wynrcju@mydomain:

ham.twrv9q1qj@mydomain:

То есть, учетка админа имеет два алиаса, три других алиасов не имеют. Не смог на скорую руку с помощью sed/grep/awk убрать строки, после которых нет алиасов, да и черт с ними: вычистил вручную в редакторе.
Теперь надо подготовиться к автоматическому прописыванию алиасов из этого файла. Любым способом делаем глобальную замену "zaimbraMailAlias:" на "zmprov aaa $1 " (перед закрывающей кавычкой на всякий случай лишний пробел!).
Опять же, не смог оперативно понять, как это сделать штатными средствами, поэтому в редакторе, уже вручную убрал все оставшиеся двоеточия и перед каждым емайлом дописал "set ", чтобы присвоить первому переданному параметру командной строки значение этого емайла:

set admin@mydomain
zmprov aaa $1  root@mydomain
zmprov aaa $1  postmaster@mydomain

Полученный после всех издевательств файл снабдил шабангом и запустил на выполнение.

Zimbra: перенос на другой сервер. Часть 2014-1

Несмотря на радостный оптимизм в сентябре 2012, реальный перенос прошел совсем не так гладко.

Начнем с того, что установить 6.0.15 поверх скопированной с боевого сервера просто не удалось. Как ни бился, но сделать ничего не мог - то вдруг ldap терял данные, несмотря на правильный перенос (через zmslapcat), то zimbramon/64 вдруг начинал обращаться к старой библиотеке, которая еще /486, то еще что-то непонятное вылезало.

В общем, плюнул я на всё и решил ставить с нуля 8.0.6/64 на 12.04. Скоро, правда, появится 14.04, но это уже не так страшно.

По ходу дела выяснилось, что набор зимлетов, активированных в админке по умолчанию несколько отличается от того, что был в 8.0.0. Например, зимлета миграции учетных записей там не оказалось. Однако, сами зимлеты в виде zip-архивов лежали в нужном каталоге в /opt/zimbra.
Лихо жму в админке "инсталляция..." и понимаю, что мне предлагают из браузера выбрать файл на моей рабочей станции, а не из упомянутого каталога. Пришлось скопировать zip-ы к себе и ставить уже отсюда. Вроде поставились, я даже увидел знакомые буквы... Зимлет "просмотр почты" во времена 8.0.0/8.0.1 вызвал неслабое бурление говн на форумах, но в конце концов его официально включили в FOSS-версию, что не может не радовать.

Учетные записи этот мастер переноса создал, молодец. Но почту не перенес. Зато вроде без ошибок указал почтовый сервер каждого пользователя, не пришлось править поломатые.

Сейчас стоят две задачи: перенос сообщений и индивидуальных настроек, а также дополнительных объектов LDAP - списков рассылки и т.п.

Под катом размышления по этому поводу.

parole и gmusicbrowser требуется плагин text/html decoder для MP3 ???

Бред, не правда ли? Что за декодер html может быть нужен для воспроизведения локального файла, созданного еще в 2006 году, который до этого бессчётное количество раз прекрасно воспроизводился.
Однако, факт: gmusicbrowser заявил, что отсутствует некий модуль из gstreamer, а parole уточнил, что нужен именно декодер гипертекста. Ага, для оцифрованной музыки нужен декодер гипертекста. Ну просто жизненно необходим!
Audacious и VLC молча проглотили файл и прекрасно его воспроизвели. Почему-то я не думаю, что у них в штатной поставке есть такой декодер.
У меня установлены все плагины gstreamer-0.10 и gstreamer-1.0, включая bad и ugly, не установлены только совсем уж экзотические.

Поиск не дал ничего интересного - у большинства, у которого всплывала проблема, она касалась потокового воспроизведения из интернета и обычно свидетельствовала о том, что выбран неправильный URL для потока. По понятным причинам мне это не помогло.

Стал разбираться, в т.ч. и сравнил этот файл с соседними, взятыми в то же самое время с того же самого сайта. Сначала gmb показал, что частота дискретизации в этом файле 32000Гц, тогда как остальные инструменты показывали 44100Гц (или как-то так).
Потом посмотрел свойства файла в thunar и несколько удивился: он показывал все параметры аудио по нулям, в то же время сообщая корректные данные (дискретизацию, продолжительность и т.п. для соседних файлов).

Пришлось прибегнуть к "швейцарскому ножу" - VLC. Сказал ему конвертировать этот файл в MP3 и т.д. Через пару секунд получил новый файл, который прекрасно воспроизвелся gmb и parole.

Вопрос: что это было? Не похоже, чтобы файл был поврежден. Может проблема где-то в обновленных после апгрейда до 13.10 кодеках, которые несколько отупели?