Периодически возникает задача миграции из одной почтовой системы в другую. В связи с тем, что часто эти системы не имеют штатного функционала сосуществования, их совместное использование может оказаться не самой простой задачей. Переход из одной системы в другую может выглядеть так — начиная с вечера пятницы системный администратор осуществляет настройку серверов, перенастраивает почтовые клиенты пользователей и переносит пользовательские данные. Несмотря на его старания, понедельник может оказаться очень «веселым» днем: или не все данные перенеслись, или какая-то старая система не может отправлять сообщения.
Мне хотелось бы рассказать про другой вариант совместного использования почтовых систем, благодаря которому можно добиться плавной миграции пользователей и сгладить возможные проблемы.
Для дальнейшего описания я буду использовать конкретные почтовые системы, но постараюсь сохранить применимость данного описания и для других систем. В качестве старой почтовой системы я буду использовать Microsoft Exchange 2013, а в качестве новой почтовой системы будет выступать Google Apps for Business. За рамками данной статьи находится процесс миграции пользовательских данных, так как он очень сильно зависит от текущей и будущей почтовых систем.

Хотелось бы выделить 2 ключевых этапа сосуществования. Основное назначение первого этапа — это проверить, устраивает ли вас функциональность новой почтовой системы. Во время второго этапа происходит основная миграция пользователей.

Доброго всем времени суток!

Представьте ситуацию: у вас есть хорошо настроенная и отлаженная система под управлением Debian. В какой-то момент вы хотите сделать так, чтобы эта система установленная на HDD начала загружаться с флешки или с CD-диска и работать в режиме ReadOnly. Типичное применение подобного решения это различные уличные киоски или тонкие клиенты, состояние которых сбрасывается в исходное при каждой перезагрузке.

Сегодня я хочу рассказать о том, как добиться подобного результата, но сначала немного теории.
Как известно, операционная система Linux Debian будучи установленной на HDD состоит из 4 достаточно независимых компонентов, каждый из которых можно подобрать или настроить по своему вкусу, а именно:

1. Загрузчик — то, что отрабатывает после BIOS и загружает Debian. По умолчанию используется «GRUB», но можно использовать любой другой. Мы будем использовать Syslinux, т.к. умеет грузить ОС с флешки, CD-диска и по сети.
2. Kernel или «ядро» — собственно центральная часть ОС, вокруг которой все крутится. Будем использовать то, что идет в составе дистрибутива.
3. initrd — промежуточная файловая система, которая помогает ядру найти RootFS. Требует небольшой модификации, к счастью не ручной.
4. RootFS — корневая ФС. Вот ее то нам и предстоит преобразовать так, что бы ОС могла грузиться в режиме RO.

Пожалуй, самым уязвимым местом современных защищенных смартфонов являются сенсорные экраны. Такие аппараты можно без особых опасений топить и валять в песке, но вот ронять их стоит аккуратно – а вдруг упадет экраном вниз, да еще и на камушек? Понятное дело, что уронить что-либо аккуратно и при этом случайно практически невозможно, такие ситуации случаются внезапно. Соломки заранее не подселишь, а бутерброд (в данном случае его эквивалентом выступает смартфон) чаще всего падает маслом (сенсорным экраном) вниз.

Помнится, полгода назад мы с товарищем устроили весьма серьезные испытания смартфону teXet X-Driver, и ему удалось сохранить честь и достоинство. Но все могло сложиться и по-другому: после каждого броска мы с опаской смотрели на экран – вдруг все же треснул? Так вот, если защищенный аппарат вам все же нужен, а связываться с «сенсорниками» не хочется, стоит смотреть в сторону внедорожных кнопочных телефонов. Сегодня речь как раз об одном из них – teXet TM-511R.

Подготовку нового сервера к работе следует начинать с настройки резервного копирования. Все, казалось бы, об этом знают — но порой даже опытные системные администраторы допускают непростительные ошибки. И дело здесь не только в том, что задачу настройки нового сервера нужно решать очень быстро, но еще и в том, что далеко не всегда бывает ясно, какой способ резервного копирования нужно использовать.

В данной статье хочу поделиться своим опытом организации работы системы мониторинга ИТ. Здесь будет рассмотрен один из возможных вариантов решения именно организационных задач, технические аспекты современных систем мониторинга обсуждаться не будут.Хочу сразу уточнить, что объектами мониторинга в моем случае являются исключительно компоненты ИТ, это: серверы, операционные системы, базы данных, транзакции и т.д.

Некоторое время назад я опубликовал этот опус в своем блоге. Сейчас наступает пора очередного переезда и я, перечитывая собственные записи трехмесячной давности, решил поделиться таковыми с сообществом. Поскольку подходящего блога не нашлось, сначала опубликовал в личный, а теперь решил создать коллективный блог, посвященный инфраструктурным вопросам, в который и переношу эту запись.Итак, получилось так, что компании, в которой я тружусь пианистом, пришлось переехать — чуть раньше назначенного времени и чуть не туда, куда планировалось =) Собственно, сам по себе переезд относительно небольшой (50 мест) сети — невеликая проблема, но в данном случае все осложнялось рядом факторов:

1. До последнего момента никто не знал, куда-таки мы едем
2. Времени, как следствие из (1), было катастрофически мало
3. Под переезд были запланированы мероприятия по полной замене парка сетевого оборудования и телефонной станции (точнее, до этого собственной телефонной станции у нас просто не было:))

Еще за неделю до того, как нам надо было освободить занимаемое помещение, мы ездили и смотрели разные офисы на предмет их пригодности к внезапному заезду — наличие и состояние СКС, электрической сети, общее состояние офиса… Вариантов было отсмотрено очень много, но беда в том, что реально пригодных ко въезду не было.

Должен заметить, что пять или шесть просмотренных офисов были близки к тому, что мы были готовы в них заехать, но основным препятствием было то, что там совершенно по-идиотски была реализована СКС. К сожалению, проектировщики (даже в очень навороченных бизнес-центрах) думают, по всей видимости, задницей — иначе, как объяснить, что на 600 квадратных метров офиса предусмотрено всего 30 мест СКС по два порта? Но это лирика, впрочем…

Внезапно, за три дня до момента X, подходящее помещение было найдено вблизи м. Площадь Ильича — и удаленность от центра, и состояние офиса и инженерных сетей более или менее отвечало нашим потребностям. Дальше — понеслось.

Статьи вида «у меня сделано вот так» полезны как читателям так и авторам: читатель увидит чьи-то решения, возможно, применит их у себя; автор – прочитав комментарии, увидит свою систему со стороны, глазами других специалистов.

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

Многие из клиентов нашей компании сильно озабочены вопросом безопасности доступа к 1С через интернет. Особенно обостряет эту проблему ситуация, когда бухгалтера хранят свой пароль на стикере, прилепленном на монитор. При таком раскладе введение дополнительных требований к сложности пароля и регулярному его изменению погоды не делает.

Чтобы максимально исключить влияние человеческого фактора мне поставили задачу организовать двухфакторную аутентификацию для веб-доступа к 1С. Ниже подробно о том, как это работает.

Этот пост понравится мизантропам: ведь он про то, что нет ничего бесполезнее, чем чужой успех. Вот если бы было место, где люди честно бы делились своими планами, а потом можно было бы следить поэтапно за их реализацией и фиксировать не только удачи, но и провалы в итоге… Ой, я же пишу в блоге такого проекта. Заходим на «СмартПрогресс», выбираем меню Цели, сортировку «проваленные», добавляем параметр «лучшие за все время» — и смотрим список самых громких фейлов на проекте.



Поскольку каждая история сопровождается подробным описанием, можно разобрать причины чужих неудач достаточно подробно — настолько, насколько пользователи позволяют себе быть откровенными. Ведь мы не хотим совершить ошибку, которую совершают все, кто изучают чужие истории успеха, забывая истории неудач – ошибку выжившего.

Где-то 3 месяца назад в нашей фирме поднялся вопрос о регистрации обращений пользователей в IT отдел. Мне было поручено просканить интернет на предмет системы учета заявок, такого себе хелпдеска. Требования были предъявлены следующие:
1. Бесплатность (да-да, платить за эту систему отказались).
2. Возможность сбора статистики (для больших боссов).
3. Сигнал на почту (не только админам, но и пользователям, а так же всем заинтересованным именно в этой заявке лицам).
4. FAQ и база знаний.
Сказано — сделано. Так как все эти системы для меня были в новинку, то по совету на каком то из форумов я выбрала GLPI. Тем более, что эта система обещала облегчить процесс инвентаризации, что является довольно неплохим бонусом!

Итак, давно стояла задача купить себе EDC (Everyday carry) фонарь-наключник. При выборе выделил три основных критерия: работа от элементов питания типа АА, относительно компактные размеры, базовая пылевлагозащита и, конечно же, должна быть фича! В итоге выбор пал на фонарь из популярной нынче категории "умные девайсы" — Nitecore SENS AA. Где той самой особенностью является возможность изменять яркость свечения в зависимости от угла наклона относительно поверхности земли.

С каждым днем количество электроники которую человек берет с собой за пределы дома растет, и несмотря на ее тотальное уменьшение и облегчение, количество гаджетов у отдельных особей может составлять весьма длинный список. Встает вопрос: в чем носить? Да так, чтобы удобно и безопасно для электроники? Сегодня расскажу о годном гик-рюкзаке на 32 литра Thule TCBP217 ну, и конечно же, всех приглашаю в EDC тред.


Осторожно: много картинок!

Недавно купил вот такую красоту.
Поигрался с Android на ней и решил сделать домашний сервер на замену RaspberryPI.

Хабражители редко ходят друг к другу в гости. И, в то же самое время, хотят взглянуть на то, как устроились другие. Может быть, даже, позаимствовать разные интересности.

Пока вы дома, самое время вооружиться фотоаппаратом и поделиться видом своего рабочего места (домашнего).

По возможности, описываем:
1. 7 любимых гаджетов.
2. 7 ежедневных программ.
3. 7 интересных открытий, которыми вы часто пользуетесь.

Приоткройте занавесу тайны в своей обители.

PS: Бонус для владельцев ноутбуков — подключаем 2 монитора.

В данный момент в Linux существует следующие широко известные реализации контейнеров:

• Vserver
• OpenVZ

Но они требуют наложения своих патчей на ядро, для получения необходимого функционала. В отличии от них lxc начиная с ядра версии 2.6.29 не требует этого. Для реализации изоляции используются уже имеющиеся в ядре namespaces, а для управления ресурсами Control Group. Это позволяет создавать не только полноценные изолированные окружения, но и осуществлять изоляцию отдельно взятых приложений.

Изучая на Хабре различные GTD подходы, натолкнулся на Технику Помидора (название зацепило). Прочитав методику, мне она показалась достаточно занимательной. Есть варианты на итальянском, английском, китайском, а на русском нет — я подумал, что было бы неплохо иметь русский перевод, и не найдя его решил перевести сам.

Техника Помидора — методика управления временем, предложенная Франческо Цирилло в конце 1980-х. Техника предполагает разбиение задач на 30-минутные периоды, называемые «Помидоры» (25 минут — работа, 5 минут — перерыв). Каждые 4 Помидора — длинный перерыв. Т.е. если совсем кратко: заводишь кухонный таймер и работаешь без перерыва 25 минут. После звонка — ставишь в табличке напротив конкретного дела над которым работал крестик, передышка 5 минут — и стартуешь очередной Помидор. Если тебя что-то отвлекает — не начинаешь над этим думать или делать, а записываешь «на потом» — и после, во время перерыва, например, уже думаешь, что с этим делать.

Для программистов, боюсь, техника не сильно подходит (т.к. поток), но для тех, кому приходится сталкиваться с большим количеством «отвлеканий», может подойти (идеально для учащихся).

В процессе перевода натолкнулся на то, что некоторые вещи непросто перевести — например interruption. Перевести просто как прерывание — наверное, неправильно, притом, что такое слово может вызвать у хабрааудитории совсем другие ассоциации из мира ПО. Поэтому решил наименовать это отвлеканиями. Хоть и нет в русском языке такого слова, но в данном конкретном контексте мне показалось перевести так наиболее близким по смыслу.

В целом, замечания и комментарии приветствуются.

Кнопка — не самая обычная бухгалтерская компания, но бухгалтерию мы ведём в 1С, как и большинство отечественных коллег. На текущий момент у нас на сервере проживают сотни баз, поэтому нам пришлось научиться быстро и качественно всё это богатство администрировать. Если вы — бухгалтерская компания, хостер с сервисом 1С, или у вас просто откуда-то взялась куча 1Сок, вы знаете, как это трудно. Мы любим приносить пользу, поэтому поделимся опытом, практическими советами и инсайтами, которые успели нас посетить за бессчётное количество ночей, праздничных и выходных дней, проведенных за обновлением и актуализацией всего нашего хозяйства.



Мы не продаём 1С, а потому рассказ будет без купюр, цензуры, а главное — без маркетингового булшита. Бонустреком, по ходу поста можно найти несколько полезных скриптов и советов для тех у кого действительно много баз 1С.

Как-то раз коллеги из отдела HR i-Free обратились ко мне с просьбой написать небольшую статью для молодых специалистов, которые стремятся устроиться в IT-компанию. Причины, побудившие их это сделать в целом понятны, в компании основным нанимателем молодых специалистов является отдел под моим управлением, мы берем только что закончивших вуз ребят (а иногда и студентов последних курсов), и у нас они проходят некий курс «молодого бойца».
Естественно, я не претендую на объективность, а лишь хочу дать несколько советов для тех, кто хочет начать свой путь с работы в IT-компании. Статья выражает сугубо моё мнение о том, как нанимать молодого специалиста, и очень надеюсь, что кому-то из студентов старших курсов сей краткий опус поможет в будущей карьере.
В общем, тех, кому интересно, прошу под кат.

Добрый день, друзья. В этой статье я хотел бы рассказать, о чем стоит задуматься, прежде чем настраивать систему резервного копирования баз данных. Несмотря на то, что в первую очередь рассматривается использование данного подхода с MS SQL Server, принципы, изложенные здесь, легко проецируются на любую другую технологию. Ну что ж, поехали.

Добрый день, статья написана в качестве некоего продолжения данного опуса. Компания 1С довольно часто подвергается критике, нередко объективной, но я попытаюсь своим примером показать, что 1С предоставляет свободу выбора, что в нынешнее время как минимум заслуживает уважения. Также немного посчитаем деньги.