• ↓
  • ↑
  • ⇑
 
Записи с темой: этот безумный мир (список заголовков)
22:07 

WebMarshal 6.x

Stance Dance

Что такое WebMarshal? Это контент-фильтр, работающий в паре с прокси-сервером, хотя и сам может выступать в роли последнего. Его задача - более детальное исследование трафика, который идет в Интернет и оттуда, с целью отсечения нежелательного материала. Отличие от обычного прокси в том, что контент-фильтрация режет пользователей не только и не столько по адресам, а по содержанию тех страниц, что пользователи пытаются посетить.
Поработав немного с этой программой и вникнув в ее логику построения правил, нашел ее очень удобной, но есть одна ошибка, которая в последнюю неделю мне попортила изрядное количество крови. Суть ее в следующем.
В своей работе WebMarshal может использовать как свою собственную базу пользователей, так и базу Active Directory. Последнее весьма удобно, не нужно "плодить сущности", как многие говорят. Не буду вдаваться в тонкости организации этой структуры, перейду сразу к делу.
Если пользователь, будучи уже импортированным из Active Directory меняет свое расположение в структуре OU (организационных единиц - читай, в другую перекинули его), при следующем же сеансе обновления информации из Active Directory WebMarshal такого пользователя не найдет. Он упорно будет пытаться найти его в старой OU. Эта ситуация разобрана на самом сайте WebMarshal - вот ссылка на страницу:
Moving Active Directory users between OUs - Клац!

В статье указывается, что проблема эта была решена в версии программы 6.1.6. Не подтверждаю. Используется версия 6.1.7 - ошибка сохраняется. В качестве решения предлагается связаться с технической поддержкой WebMarshal.
Что ж, разумно. В конце концов, тех. поддержка на то и нужна, чтобы решать такие вопросы. Но ведь хочется самому понять, в чем неприятность.
А неприятность заключается в следующем. WebMarshal не работает напрямую с учетными записями в Active Directory. Он создает их реплику в собственной базе. И именно эту реплику он каждый раз обновляет во время синхронизации с Active Directory. Вот только почему-то если WebMarshal видит, что запись в AD обновлена, у себя он не изменяет существующую запись, а создает новую. И все бы ничего, но если попытаться показать список группы, которая содержит переехавшую учетку, это приведет к чтению базы из WebMarshal с ее одновременным обновлением из AD. А в базе WebMarshal будет прочитан сбойный элемент, которого в AD уже нет на старом месте. После чего программа впадает в ступор и выкидывает сообщение об ошибке.
Ручная очистка базы из консоли WebMarshal нужного результата не дает. Сбойная запись по-прежнему где-то сидит и мешает жить. Наконец, было принято решение на свой страх и риск залезть напрямую в SQL базу. Найдя там таблицу dbo.User и открыв ее, я пришел в ужас. Сколько раз была добавлена та учетка, будучи в разных OU, столько раз она и содержалась в базе, несмотря на все сеансы очистки из консоли. Дальнейшее уже тривиально. Смоделировать еще раз ошибочную ситуацию, выписать ID той записи, что сбоит, и грохнуть ее из всех таблиц, которые к этой записи могут относиться.
Согласен, метод весьма жесткий, но иногда приходится действовать и так.

UPD. Только сейчас пришло в голову, что можно и не удалять сбойную запись, а всего лишь выправить значение в поле Name, там, где указывается DN этой записи. В итоге исправление нужно будет вносить только в одной таблице. А это уже куда проще и приятнее для базы в целом.

@темы: Security, Этот безумный мир

11:07 

Mailflow

Stance Dance

Слежение за тем, как ходит почта от одного адресата к другому - занятие весьма интересное. Интерес там представляют ошибки, если таковые имеются. Совсем недавно пришлось разбираться с уникальным случаем в моей практике.
Ситуация: звонок сотрудника А с сообщением о проблеме: его письма доходят до стороннего человека Б. Но когда Б нажимает кнопку "ответить" и отправляет ответ, письмо уходит в ящик сотрудника В, о котором Б не имеет никакого понятия.
Вот такая вводная, дальше идет собственно разбор полетов.
Первое - ключевыми словами здесь для меня явились Б нажимает кнопку "ответить", это действительно важно. Те, кто использовал в своей практике почтовик The Bat, и помнят, как там настраиваются учетные записи почты, меня поймут. Для непосвещенных объясню. В The Bat можно менять значение поля Reply-to. Это поле содержит в себе тот адрес, на который будут отсылаться ответы на пришедшее письмо. Если объяснять на пальцах, получится следующее:
Вы настраиваете учетку на работу с адресом 1@1.ru, это ваш основной адрес. В поле Reply-to ставите другой: 2@2.ru. Все. Ответы на все письма (именно ответы), будут идти к вам на адрес 2@2.ru, в то время как в поле From будет светиться по-прежнему 1@1.ru.
Навскидку я не смогу придумать примеров использования этой схемы, но если ее реализовали, стало быть кому-то это было нужно.
Второе - по уверению сотрудника А, человек Б использует веб-интерфейс Яндекса.
Третье - у нас на предприятии The Bat не используется, стало быть поле Reply-to можно списывать со счетов, тем более, что по-умолчанию оно содержит в себе основной адрес, а я не помню, чтобы хоть для кого-то когда-то его меняли специально.
Четвертое - после проверки учетной записи А выяснилось, что никаких пересылок, перенаправлений и тому подобного добра не установлено. Почта ДОЛЖНА приходить в почтовый ящик А.

Что ж, проводим следственный эксперимент. Отсылаю тестовое письмо с ящика А на свой собственный, расположенный на стороннем сервере. Письмо приходит. Давлю кнопку "ответить", вбиваю "Тест" в тело сообщения, жму "Отправить". Письмо падает в ящик А, как ему и положено. Уведомляю сотрудника, что с его учетной записью все в порядке, и он может спокойно отсылать почту. А сам думаю, ЧТО было не так.
Для того, чтобы письмо попало в какой-либо ящик вообще, необходимо, чтобы в этом письме было хоть одно упоминание адреса, куда это письмо доставить надо. В тексте письма нигде ящик В не встречался, но ведь текст - это еще далеко не все.
Опять же - спасибо почтовику The Bat и его полезнейшей функции Исходное Сообщение. Знаем, помним, любим. Благо, мой сторонний ящик поддерживает эту возможность - открываю код сообщения и в поиск вбиваю адрес ящика В. Нашелся. Угадайте, где. В ПОДПИСИ СОТРУДНИКА А!
В подписи по стандарту компании указывается электронный адрес каждого сотрудника. Обычно это ссылка почтового стандарта mailto:. Как правило пользователи не в курсе, что ссылка состоит из двух частей - текста ссылки и цели ссылки. В нашем случае текстом в подписи был прописан ящик А, а целью был ящик В. После того, как это было замечено в коде письма, все стало ясно.
Вот честно, я бы очень, ОЧЕНЬ хотел посмотреть на человека Б, который утверждал, что отсылал ответ на письмо А, используя функцию "Ответить". НЕ ИСПОЛЬЗОВАЛ ОН ЕЕ, ни разу. Он тупо клацал мышкой на ссылке в конце письма от А, а ссылка, как выяснилось, была битой.
И второй вопрос - кто и как настраивал распроклятую подпись у сотрудника А? Этого узнать, к сожалению, не удалось, хотя обычно сотрудники сами себе подписи ваяют...

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

@музыка: Rian Farish - Breakthrough

@темы: MS Exchange, Этот безумный мир

10:52 

Limits.

Stance Dance

And I push her to the limit
to see if she will break.
---
(c) Pink Floyd - Take it Back

Согласно политике почта сотрудников, покинувших компанию, не удаляется. Она перемещается из оперативной базы данных в специально выделенную, это снижает нагрузку на сервер. Лимитов на почтовые ящики нет. Пока нет, скоро будут, ибо размеры оперативной базы лично меня уже пугают. Буквально вчера перемещал хороший такой ящичек на 4 Гб весом, смотрю, какие папки перемещаются, сколько писем в них. 19 с плюсом тысяч сообщений, 6 тысяч из них находятся в папке Удаленные. Хочется сказать матерно, но сдержусь. Больше всего повеселил тот факт, что последней была перемещена папка "Важное", в которой находилось всего 14 писем. 14. важных. писем. Из более чем 19 тысяч. Получается, что вся остальная масса сообщений - есть ненужный балласт. Полагаю, после такого есть, над чем подумать.
Люди, пожалуйста, если у вас нет ограничений на размер почтового ящика на работе - не стоит хранить в нем переписку буквально за все время вашей работы. Пожалейте ваших админов, пожалейте ваши серверы, пусть даже вы их никогда не видите, и они железные. Чем больше база писем, тем она медленнее и неповоротливее. Тем хуже она будет проходить резервирование, и тем больше шансы на то, что в случае краха восстановить ДЕЙСТВИТЕЛЬНО важные письма не удастся. Пожалуйста, подумайте над этим.

@темы: MS Exchange, Этот безумный мир

21:50 

Море между городами - по колено, океан между континентами - по пояс.

Stance Dance

Любопытная история. Как всегда - разбор полетов письма, почему не доходит до адресата. Все началось с получения отбойника вот такого вида:
**********************************************
** THIS IS A WARNING MESSAGE ONLY **
** YOU DO NOT NEED TO RESEND YOUR MESSAGE **
**********************************************
В общем-то, все просто и понятно. Письмо задержано, повторная попытка его доставить все таки будет. Проблема в том, что письмо срочное. Выискиваем номер телефона компании, в которую это письмо улетело, и начинаем выцарапывать информацию.
Приятный женский голос в трубке сказал, что по проблеме вряд ли что сказать сможет, ибо не в курсе, но может переключить на специалиста. Ну что же, спасибо, подожду. Разговор со специалистам позабавил. Суть в том, что письмо ушло на ящик login@domain.ru. На что с той стороны после минутного раздумья (видимо тоже у кого-то справлялся человек, что и как) был задан вопрос: А откуда вы узнали о существовании этого адреса?
Опа! Вот что б я еще знал, откуда наш сотрудник его узнал. На том конце меня просвещают, что все электронные адреса компании имеют вид login@domain.com, так что можно продублировать письмо, и оно должно дойти до места назначения. Благодарность за информацию и вежливое прощание. Стороны беседой удовлетворены.
А дальше - дальше трубку к уху и вызванивать сотрудника, где и как на адрес в RU домене напали. Ответ порадовал. Девушка на телефоне в той компании, куда письмо летит до сих пор, сообщила, что можно прислать информацию на адрес %login%. А на уточнение по поводу полного адреса был получен ответ вида: "ну %login%, а после собачки - как всегда". Поскольку звонили по России, легко предположить, что и адреса будут российские. Вот и полетело письмо "на деревню дедушке Константин Макарычу".
Люди, когда диктуете кому-то электронный адрес - диктуйте его полностью. Всегда. Это может сократить кучу времени и нервов в дальнейшем.

@темы: MS Exchange, Этот безумный мир

18:38 

Support

Stance Dance

Есть на этом свете славная компания HTC, выпустившая немало славных коммуникаторов. Дорогих и не очень, навороченных, и менее функциональных. WM-based и Android-based. Вот о последних речь и пойдет.
Недавно возникла задача - подключить коммуникатор сотрудника (HTC Hero) к корпоративной почте. Все бы ничего, но при проверке соединений используется самоподписанный сертификат. Знающие люди поймут сразу, о чем сыр-бор, а для незнающих поясню. Дело в том, что таким сертификатам не доверяет ни одна система. Даже та, которая этот сертификат и подписала для себя. И для того, чтобы она стала ему доверять, корневой сертификат центра сертификации (сорри за тавтологию), должен быть напрямую импортирован в систему. Тогда последняя начнет доверять этому корневому, а следом за ним и всем сертификатам, которые этот корневой подписал.
Чем это неудобно для владельцев коммуникаторов. Эти устройства при обнаружении самоподписанного сертификата просто отвергают соединение с выводом сообщения об ошибке. WM-based коммуникаторы "пролечиваются" очень просто - сертификат копируется на них в их файловую систему, после чего в стандартном Проводнике добавляются в хранилище сертификатов. Все, устройство готово к работе.
В случае Android-based устройства (коим и является HTC Hero) получили самый настоящий геморрой. Дело в том, что у данной конкретной модели просто НЕТ Проводника или любого другого метода просмотра файловой системы. Можно обратиться к музыке, к картинкам, но только через соответствующие программы. Они работают на основе каталогов, которые сами же и составляют. Всякий, кто работал с библиотекой Windows Media Player - меня поймет. Но сертификат, лежащий на карте памяти телефона - это не картинка, не музыка, даже не какой-либо офисный документ. И никакая программа из поставляемых "в коробке" его не видит.
В интернете лежит куча шаманских методов сертификата, но 100%-но работающего нет ни одного. В итоге решил, как самый обычный пользователь обратиться в поддержку компании HTC, благо, на сайте есть специальная веб-форма. По логике вещей, уж компания-производитель должна что-то дельное подсказать. Сказано - сделано, написал, нажал кнопку отправить, и стал ждать. Дождался, ниже привожу запрос и ответ. Это феерия!

Запрос
Добрый день. Хотелось бы уточнить, каким образом можно настроить телефон HTC Hero так, чтобы он доверял самоподписанному сертификату Exchange, используемом в организации. В настоящее время телефон при попытке доступа к серверу через защищенное соединение выводит сообщение о том, что сертификат не является доверенным, и предлагает либо продолжить, либо отменить соединение. При продолжении снова появляется окно о недоверенном сертификате, и так повторяется бесконечно.
В общем случае для решения проблемы нужно импортировать на устройство корневой сертификат, но как это можно сделать на данном телефоне?
Заранее благодарен за ответ.


Ответ
Добрый день!
Спасибо за обращение в HTC.
Коммуникатор на базе ОС Android автоматически прописывает сертификаты. Если Ваш аппарат показал извещение об ошибке сертификата, то обязательно выбирайте пункт "продолжить" и коммуникатор загрузит нужные данные.
Пожалуйста, обратите ваше внимание, что вы можете также связаться с нами по телефону.Для более детальной информации пожалуйста перейдите по ссылке www.htc.com/uk/CA_Hotline.aspx
С уважением, НТС.


Если честно, после подобного ответа у меня не остается никакого другого выбора кроме закрытия запроса. И заодно я уверился во мнении, что если даже когда-то и приобрету себе смартфон, это не будет Android-based.

@темы: Этот безумный мир, Android

20:32 

MS Exchange 2003 Log files

Stance Dance

Потихоньку прихожу в себя от сегодняшней мозголомки. Умом понимаю, что такие проблемы, как эта, надо ценить и коллекционировать. Когда становится бессильным даже гугл - that's a challenge. Впрочем, обо всем по порядку.
Итак, есть задание - перенести базы с одной системы хранения данных (назовем ее ареной), на другую такую же систему. Первая арена предназначена под тотальный апгрейд и переконфигурацию. Обе арены подключены к серверу Exchange, разделы сконфигурированы и видны, как диски. Все готово для переноса, процедура которого весьма обыденна - нужно отмонтировать нужную базу данных и перебросить ее файлы в нужный каталог. С этим проблем не возникло никаких. База успешно поднимается, лежа уже в новой папке на новой арене.
После копирования файлов базы было решено сразу же завершить копирование группы хранения, в которой эта база находится. Это включает в себя перенесение chk-файла и файлов логов группы. Сказано, сделано. Подготовлены каталоги, отдана команда на перенесение одного, потом другого. Все успешно. Курсор мыши зависает над пунктом Mount Database. Один щелчок кнопкой, и...
Произошла внутренняя ошибка обработки. Попробуйте перезапустить диспетчер Exchange System Manager или службу Microsoft Exchange Information Store, или обе службы.
Код события: c1041724
Exchange System Manager


Первый звонок о том, что что-то пошло совсем не так, как планировалось. О перезапуске Information Store речи не идет, downtime будет не запланированным, отчего по голове не погладят. Первым делом смотрим в логи. Computer Management, Event log, Application...

Description: "Information Store Unable to read the header of logfile Exx.log. Error -530

Много непечатного. Очень много. Потому что весь интернет с MS во главе при такой ошибке дают два варианта действий: либо восстановление из бекапа, либо... eseutil /p, о котором мне писать уже доводилось. Спасибо, не надо, это долго. Да, я знаю, что у меня проблема с базой, но это не основная база, потому есть время на размышления.
Первым делом предпринял попытку вернуть логи назад... к моему великому удивлению - база примонтировалась и спокойно заработала без каких-либо ошибок. Мистика. Повторное отключение и перенос на новую арену. Результат описан выше. Снова возвращаю логи в исходную папку. Работает. Мистика дважды. Ради интереса переношу логи на системный раздел сервера Exchange - все работает. Возвращаю назад и логи, и базу (копия осталась в исходной папке) и ложусь спать, потому что время на тот момент было уже два часа ночи (работал из дома).
По приходу на работу утром предпринимаю еще одну отчаянную попытку переместить логи на новое место, только создал для этого тестовую группу хранения с тестовой базой внутри. Как легко догадаться, за ночь ситуация лучше не стала. База отключена, состояние - Clean Shutdown, то есть для ее работы логи в принципе не нужны. Что ж, копирую их в безопасное место, после чего уничтожаю их на новой арене, проверив, что сам Exchange будет их искать там. Расчет был на то, что даже если файлы и портятся при копировании, сервер просто создаст новые логи на новом месте. Это вполне допустимо, если есть резервная копия (она есть). Хотя и непонятно, почему при обратном копировании все работает, ведь файлы могут быть повреждены. К моему великому удивлению, логи создались на новой арене без проблем и вся база данных успешно примонтировалась.
Следующая стадия эксперимента - перенесение этих новых логов с новой арены в какую-нибудь папку на старой. Неудача. Та же самая ошибка, и то же самое восстановление работоспособности после перенесения их в их "место рождения", то есть на новую арену. Ради интереса переношу их на системный раздел, ожидая увидеть ошибку. Не ошибся.
Получается очень интересная ситуация. Логи, созданные вне новой арены, можно таскать куда угодно, но только не на новую арену. Логи же, созданные на новой арене, можно таскать как угодно на этой арене, но вне ее база работать отказывается. Чувство, что файлы на арене кодированы, но никто никакой кодировкой не занимается.
Дальше идет несколько часов курения гугла, всевозможных манов, форумов и им подобного. И везде одно и то же - бекап, eseutil. В голове третий вариант об отказе от старых логов для всех групп хранения и создании их на новой арене. Но это неправильно, потому что в прошлый раз при перенесении баз ничего подобного не было.
Под конец дня решил повнимательнее присмотреться к логу, который выдается, как сбойный. Файл как файл, MD5-хэши одни и те же, значит он не меняется и речи о повреждении не идет. Тогда что мешает? Unable to read the header of logfile. Но это Information Store не может прочитать. А что если взглянуть на файл под микроскопом?
eseutil /ml exx.log

Результат огорошил:
Operation terminated with error -546 (JET_errLogSectorSizeMismatch, the log file sector size does not match the current volume's sector size)

О таком я не слышал никогда. Чтобы лог файл не мог прижиться на новом устройстве, размер сектора которого отличается от размера сектора диска, где лог был создан. Эксперимента ради рассмотрел живой лог и на старой арене, и на новой. Результат сказал обо всем:
Env Log Sec size: 512 - на старой.
Env Log Sec size: 4096 - на новой.

Разделы и на одной арене, и на другой, создавались без меня. И никто не придал значения параметру Sector Size в настройках слайсов рейд-массива, сомневаюсь, что сам бы это сделал. Однако, значение это имеет, и довольно большое. Проблема лишь в том, что массив перебивать уже нельзя.
В итоге все же решили остановиться на варианте создания новых логов, это будет быстрее. И как всегда, бекап, бекап, бекап.
До сути проблемы докопались, это уже хорошо. Урок и полезная информация на будущее. Надеюсь, что кому-то она сэкономит много нервных клеток.

@музыка: Fowler and Branca - Windy Sky

@темы: MS Exchange, Этот безумный мир

18:44 

Hardware...

Stance Dance

Прошедший понедельник стоил мне пары седых волос, не иначе.
Если пытаться обрисовать ситуацию двумя словами - хрень нереальная, других определений не находится, потому что такого на моей памяти не случалось никогда.
Вполне невинная процедура - вывод из домена сервера, предназначенного к полной переустановке операционной системы (плановый апгрейд до windows 2008), операция, проведенная за всю жизнь уже очень большое количество раз, ошибиться в которой можно только в одном случае - выведя из домена не тот сервер.
Выглядело все это следующим образом. Спуститься в серверную, на KVM переключиться на нужный сервер, отдать все необходимые команды для вывода из домена, перезагрузить его. А пока перезагружается, подключить почему-то неиспользуемый порт iLO (какая расточительность, однако).
Где-то в середине процесса в серверную поступает звонок из админской и вопрос - "что у нас за апокалипсис?".
В самой серверной все неизменно, только теперь уже бывший контроллер домена пущен в рестарт после вывода из домена. После этого сообщают, что по сети недоступны первый DC, почтовый сервер, шлюз. Смотрю на передние панели указанных хостов и понимаю, что двое из них - контроллер и шлюз, уже спят. Переключаюсь на почтовик, и вижу, что он в состоянии выключения операционной системы. Что за ересь?! В довершение всего этого дела намертво повисает KVM, лишая нас консольного доступа к серверам.
Ладно. DC у нас в домене не один и не два. Проживем. Шлюз - уже критичнее, почта - совсем критично. Запускаю шлюз, запускаю почтовик, запускаю DC. Первый и третий поднимаются довольно быстро. Почтовик же задумался. Дожидаюсь вывода на экран стандартного приглашения на ввод логина и пароля, и в трубку: "Проверяй, почтовик поднялся". Ответ убил - коннекта от Outlook до Exchange не наблюдается, но пинги есть. Плохи дела. Ctrl+Alt+Delete, и у меня волосы встают дыбом - Exchange выпал из домена.
Что за этим может последовать, лучше и не думать. Провести ночь в серверной борясь с конфигами, со структурой в AD, не хотелось абсолютно. Абсолютно не понимая, почему такое могло произойти, захожу под локальным админом, лезу в логи. Параллельно открываю консоли контроллера и шлюза. Офигеваю от того, что шлюз тоже вне домена. А в логах видно, что и шлюз, и почтовик выпали из домена в результате штатной операции, выполненной... мной же! Я в ауте... В голове всплывает один из давным-давно прочитанных документов о повторном присоединении рабочей станции к домену под существующим именем. Вот и появилась возможность проверить эти сведения на практике, хотя я и предположить не мог, что проверять это все буду на Exchange, для которого членство в домене - это альфа и омега.
ADUC, Find Computer, Reset Account. После чего на почтовике выполняется штатная операция присоединения к домену и рестарт. Долгие пять минут ожидания, вопрос в трубку "ну как?" и ответ: "У Егорыча почта поднялась!".
Все выдохнули. С этого момента Outlook'и медленно, но верно начали находить сервер и штатно работать с почтой. По аналогичному сценарию добавляем в домен шлюз, после чего работа сервисов нормализуется. А у нас теперь великий геморрой - найти причину этого бардака.
Логи контроллера, логи почтовика, логи шлюза, гугл. И при помощи этого всего нашли причину. Ей оказалась та самая несчастная KVM, через которую я и выводил из домена нужный сервер. Эта, с позволения сказать, железка, в результате какого-то одной ей ведомого сбоя ретранслировала все, что я вводил с консоли на нужный сервер, еще на три порта. А потом вылетала напрочь. Судя по логам всех участвующих в представлении серверов, на все 4 машины в одно и то же время были посланы одни и те же команды, в одно и то же время. У меня все же не 4 пары рук и не 4 головы, чтобы подобное вытворить. Даже комментарий к операции перезагрузки был на всех 4 машинах одним и тем же - "12". Контроллеру домена повезло, его из домена так просто не вышибить, потому он просто перезагрузился и заработал в обычном режиме. А вот почта и шлюз оказались уязвимы.
Что ж, по крайней мере, теперь точно известно, что случайный вывод Exchange-сервера из домена (дико звучит, но все же) не является фатальным. Заодно стало понятно, почему при выводе рабочей станции из домена не удаляется ее учетная запись из базы данных, и как эту учетную запись можно использовать.
Но все же иногда эти знания даются слишком дорогой ценой...

@музыка: Stone Age - Sellet

@темы: Security, Этот безумный мир

23:45 

DFS

Stance Dance
На этот раз просто DFS - Distributed File System, слава вышним, без R - Replication.
В кои-то веки решил сделать все, как говорится, по фэн-шую, чтоб красиво было:
dc-01 с адресом вида x.x.x.11
dc-02 с адресом вида x.x.x.12
Проблема в том, что второй контроллер назывался не вторым, а третьим, хотя адрес у него был уже тот, что хотелось. Вечером, когда пользователи уже покинули свои рабочие места, открыл RDP сеанс, ввел все необходимые команды для переименования компьютера (контроллеры начиная с Windows 2003 Server переименовываются так же, как и обычные члены домена), перезапустил сервер. Ожидаемо получил переключение своей машины на работающий первый контроллер, подождал, увидел, что dc-02 теперь стал именно dc-02 и уже вовсю обрабатывает запросы. С чувством выполненного долга, а так же прекрасного, ушел домой...
Наутро осознал всю глубину своей неправоты. Очень много звонков, и все с одной и той же проблемой - нет сетевых дисков. Ну два, ну три, ну пять таких звонков - это в порядке вещей, старое железо, будь оно неладно. Но когда их число перевалило за два десятка...
Начинаю вспоминать, что и как. Сетевые диски цепляются через систему DFS. DFS ссылки хранятся в AD, но обращение к ним идет через так называемые DFS Name Servers, в которые входят и наши контроллеры домена. Если клиент не может подключиться к ресурсу по DFS пути, при условии, что все права у него есть, и сеть тоже в наличии, значит он попал на Name Server, который в данный момент недоступен. В обычных условиях это допустимо, DFS такого клиента просто переключит на другой сервер, хотя на это нужно время. Но ведь все серверы активны!
Открываю оснастку DFS и понимаю, что все, да не все. Среди Name Servers по-прежнему значится dc-02, но под своим старым именем, что плохо. Ведь он по нему уже недоступен. Решение простое - удалить из списка этот сервер и добавить его заново. Удалил. А дальше - ступор, потому что повторное добавление заканчивается ошибкой. DFS говорит, что этот сервер уже является частью пространства имен, и добавить его вторично нельзя. Мол, воспользуйтесь оснасткой DFS для удаления сервера или используйте другой сервер. Приехали... Радует лишь то, что поскольку из списка DFS серверов убран сбойный - у пользователей проблем больше не будет. Но ведь надо его загнать назад, надо же все по фэн-шую...
Active Directory утверждает, что dc-02 не является частью DFS, сервер говорит ровно об обратном. Кому верить? Ответ очевиден - если DFS работает исправно, значит надо верить Active Directory. А в этом случае, нас ожидает приятное времяпрепровождение с утилитой dfsutil.exe:

dfsutil root remove <\\server\share>

Как бы не так. Ошибка выполнения и невозможность удаления DFS-ссылок. Придется действовать более жестко:

dfsutil diag viewdfsdirs < drive letter > removeresparse

Команда была выполена успешно. Все 6 ссылок убиты. Но и это еще не все. Открываем regedit и удаляем разделы по следующим путям:
HKLM\SOFTWARE\Microsoft\Dfs\Roots\Domain\DFS_ROOT
HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares\DFS_ROOT
HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares\Security\DFS_ROOT

Поскольку в этот момент мы производим "настройку" сетевых папок через реестр - для применения изменений придется перезапустить сервер. Делать нечего, перезапускаем, после чего уже спокойно делаем его полноправным сервером пространства имен в многострадальной DFS.

Фэн-шуй, говорите? Может быть оно и хорошо, но все трижды проверять никогда не помешает.

@музыка: Peter Sterling - Midnight Sun

@темы: Этот безумный мир

13:48 

Trend Micro Office Scan vs Symantec Backup Exec

Stance Dance
Переезд серверов завершен, хоть и с потерями (сижу дома и болею), надо до конца разобраться с резервированием информации. На очереди задача подружить Symantec BE и Windows 2008-based контроллер домена. И все бы хорошо, два программных продукта узнали друг друга, пожали руки и сказали - будем дружить; но не тут то было. При попытке загнать в бекап состояние системы на контроллере получили ошибку:
V-79-57344-65245 - A failure occurred accessing the object list.

Ковыряние сайта поддержки Symantec дало любопытный результат в виде статьи об антивирусе Trend Micro - Клац!
Если пересказать сжато, то проблема возникает из-за очень специфичного объявления пути к файлу одной из служб антивируса:
"C:\Program Files\Trend Micro\OfficeScan Client\..\BM\TMBMSRV.exe" (в статье рассматривается другая версия тренда, но суть та же)

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

@темы: Этот безумный мир

22:14 

Android.

Stance Dance

Да, я решил "узнать своего врага в лицо". Купил себе на пробу LG-P500, он же Optimus One.
Прошло уже больше года с того памятного мне дня, как я впервые столкнулся с этой платформой. Если уложиться в несколько слов - она обрела человеческое лицо. Как ни странно, теперь работать с телефонами на базе этой системы стало действительно удобно. Быстрые, функциональные, батарею сильно не кушающие...
Но не все так гладко, как может показаться на первый взгляд. И вот почему:
SMS are intermittently sent to wrong and seemingly random contact.
По ссылке очень много иноязычного текста, рекомендуется к ознакомлению всем обладателям андроидовых телефонов.

Сухая выжимка:
Рано или поздно любой андроидовый телефон может отослать сообщение не тому человеку. Вместо нужного адресата он подставит контакт из вашего списка, и сообщение уйдет именно ему. Что за этим может последовать - просто включите вашу фантазию.
Дата первого сообщения в этом баг-трекере - 28 июля 2010 года. Честно говоря, даже Microsoft покуривает в стороне от такой скорости реакции на события такой степени важности.

Я с этим столкнулся лично. Перерыв кучу материала и проведя несколько тестов пришел к следующему выводу - не отвечать на сообщения, используя область уведомлений. Схема работы этого бага следующая. Вы принимаете сообщение от человека А, читаете его, отвечаете или нет - неважно. Затем вы получаете сообщение от человека Б, при помощи области уведомлений отвечаете на него. Дальше вариантов два: либо сообщение уйдет человеку Б, и все довольны; либо аппарат подставит в качестве адресата того самого бедолагу А, от которого вы получили сообщение ранее, и оба участника получают конфуз.
Баг непостоянен, может проявиться, может нет, но во всех случаях подставлялся именно предыдущий абонент, приславший сообщение, не случайный.

На всякий случай, информация о телефоне:
LG-P500
ver. 2.2
Kernel 2.6.32.9
Build FRF91

На сегодняшний день все, что мы имеем по этому инциденту, это признание компанией Google проблемы и обещание выпуска заплатки в ближайшее время:
www.bbc.co.uk/russian/science/2011/01/110107_go...
Смотрим на дату новости - 8 января.

@темы: Этот безумный мир, Security, Android

22:24 

Storage switch

Stance Dance
По идее, еще пара седых волос, но все же нет, не такая история, как памятный мне полет KVM.
Итак, дано. Есть файловый сервер, подключенный к СХД по SCSI. Есть другая СХД, подключенная к другому серверу по FC, на которую через DFSR реплицировано порядка 2 ТБ пользовательского контента (да, да, все сетевые диски и тому подобное). Цель всего этого проста - старую СХД проапгрейдить до FC.
День Х, час Ч и... момент переключения хранилищ. В файловик установлен FC HBA, сервер подключен на место дублирующего, запуск.
Тест устройств показывает, что адаптер найден и опознан, ОС поднимается без вопросов. Свойства системы, управление дисками - раздел уже готов к работе, все данные видны, все на месте. Ради полного успокоения души набираю в командной строке: \\SERVER-NAME\... и понимаю, что что-то явно пошло не так. Из порядка 15 общих ресурсов видны всего 5. Админсистративные и пара завязанных на DFSR. Что делать? Без общих папок будет очень и очень много воплей.
В голове проносится мысль о том, что когда-то мне доводилось смотреть на описание общих ресурсов изнутри, в реестре. Вспоминаю, что Windows хранит информацию о конфигурации всех служб за 3 последних удачных старта системы. Что ж, придется покопаться в старине (файловик не перезагружался довольно долгое время):
Regedit, HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\LanmanServer\Shares
Bingo! Описание всех общих ресурсов на месте. Дальнейшее тривиально - экспортировать весь этот куст реестра в файл, заменить там раздел ControlSet001 на CurrentControlSet, сохранить, применить файл, перезапустить сервер. После перезапуска все общие папки вновь доступны.
Возможные потери очевидны - доступ пропадет у тех людей, кому разрешения были прописаны уже после теперь уже предпоследнего запуска файловика. Таких людей немного, и это радует.
Мораль истории - делать резервные копии. В данном конкретном случае - экспортировать куст реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanmanServer\Shares во всеми подпапками (она будет одна). Эта нехитрая операция поможет избежать несколько неприятных нервных минут.

@музыка: Yanni - Vertigo

@темы: Этот безумный мир

21:32 

Windows 2008 x64 Conversion to VMWare

Stance Dance
Windows 2008 - единственная из систем, к которой пришлось применять индивидуальный подход при ее переносе с гипервизора XenServer на VMWare. Суть в том, что при удаленном переносе при помощи VMWare Converter Standalone в режиме клиент-сервер этот самый конвертер не может найти дисков исходной системы. Нет дисков - нечего конвертировать. А посему получаем ошибку.
Что делать? Выход прост - установить конвертер прямо на исходную машину и конвертировать ее. В этом случае с дисками будет полный порядок. Веселости начинаются уже после этого.
Итак, исходная система превращена в виртуальную машину, потушена. Виртуалка поднимается, устанавливает все необходимые драйверы, инструменты... Новому сетевому адаптеру назначается старый IP-адрес, сервер видит компьютеры нашей сети, компьютеры способны найти этот сервер и по имени, и по старому IP - все счастливы. А через месяц я вижу, что Windows 2008 радостно сообщает следующее:
0xC004F00F
The Software Licensing Service reported that the hardware ID binding is beyond level of tolerance.


Приехали, система "потеряла" активацию, хотя это и неудивительно. Удивительно другое - почему она не поймала ее заново? Пытаюсь вручную сказать ей, откуда брать всю необходимую информацию:
Elevated Cmd,
slmgr.vbs -skms x.x.x.x
slmgr.vbs -ato
Не выходит каменный цветок, а судя по сообщениям, приходящим в ответ на эту команду, что-то случилось с сервером KMS, который не в моем ведении:
0xC004F039
The software Licensing Service reported that the computer could not be activated. The Key Management Service (KMS) is not enabled.


Звоню ребятам, обслуживающим этого зверя, докладываю о проблеме, на том конце обещают разобраться. Ну а пока система поживет в grace-period, уж за 60 дней всяко решим проблему, и это еще без учета slmgr.vbs -rearm.
Недавно все же решил еще покопать, что же пошло не так, тем более, что эксперимент по установке нового экзепляра Windows 2008 и активации оного прошел успешно. Следовательно, KMS работает исправно, и проблему надо искать на стороне того самого сервера.
Ipconfig /all, route print - на первый взгляд все нормально. Но ведь не все же. Еще раз для верности ввожу просто ipconfig, без ключа расширенного вывода информации... результат потряс: системе был назначен IP-адрес, была назначена маска подсети, а вот шлюз по-умолчанию - не задан вовсе.
Это что же получается, я, такая умная "маша", тупо забыл поставить шлюз? Вбиваю нужный адрес, после чего выполняю принудительную активацию (сервер активации ведь уже прописан), и система радостно говорит, что ключ найден, получен, установлен, в общем - все просто замечательно. Ладно, ошибся, с кем не бывает.
Настала пора переносить второй сервер, тоже под управлением Windows 2008, причем он довольно капризен, и если что-то пойдет не так - хлопот будет много. Все как и раньше, конвертер на машину, запуск, успешное преобразование, поднятие машины, установка драйверов, назначение старого IP. И двойная проверка шлюза, специально даже на бумажке записал. Рестарт системы и... И шлюза снова нет в списках адресов! Вот же мерзавка ;) Понятное дело, что в этом случае OCS FE просто не запустится, так как не увидит пула серверов. Ладно, хоть знаем, почему так - прописываем шлюз, еще раз перезагружаем сервер, и после этого убеждаемся, что все службы работают, все необходимые данные по сети бегают, а активация уже в автоматическом режиме пройдена.
Больше всего в этой истории смутило то, что несмотря на отсутствие шлюза сервер видел все в пределах нашей сети. Сеть же другого региона была недоступной. Да, о таблице маршрутов и on-link все же стоит помнить.

@музыка: Within Temptation - See who I am

@темы: Этот безумный мир

20:29 

UMRA - User Manager Resource Administrator

Stance Dance
Программирование без goto - Клац!
Я не случайно начал эту запись со ссылки на один из холиваров мира программирования - стоит ли использовать оператор goto при построении кода? Сам стараюсь его не употреблять ни в каком виде, благо, средств проверки условий и переходов по результату проверки достаточно. Но не в этот раз.
Довелось сегодня править код формы в этом самом UMRA. Форма работала, но после перегруппировки каталогов Active Directory работоспособность резко упала до нуля ;) Ожидаемый результат, который надо исправлять. Чем и занялся.
Итак, что представляет из себя редактор кода в этой консоли? Это достаточно прямолинейный список из заранее подготовленных команд, которые можно передать службе UmraSvc, и она уже будет их выполнять. Команд не так уж много, но и немало. Даже конструкция if... then... else поддерживается, которую я очень активно собирался использовать. Не тут-то было! Да, этот заранее заготовленный блок может проверять довольно много параметров (хотя и там нашлось, к чему придраться), но в качестве действий после проверки условия можно назначить только одно единственное! Угадайте, какое именно. Правильно - пресловутый goto!
Представить все это "великолепие" в виде псевдокода можно следующим образом:

variable1 = 5
if variable1 < 10 then goto label1 else goto label2
label1: action1
goto end
label2: action2
goto end
end:

И вот таким макаром проверять кучу условий. Повторюсь, в блоке then кроме тупого перехода к метке поставить ничего нельзя, вообще. Все дело в том, что код формы редактируется не в виде исходного кода как такового, где где угодно можно записать что угодно, а через самый что ни на есть GUI - отдельная формочка для ввода всех параметров блока if... then... else. Одним словом - такого кошмара я давно не встречал, если встречал где-то вообще.
Код этой несчастной формы в итоге был выправлен, но времени на отладку в итоге ушло куда больше, чем планировалось.
И на вкусное. Механизм проверки условий UMRA, как выяснилось, совершенно не может проверить какое-либо поле формы на непустое значение. На пустое - пожалуйста, можно выбрать тип проверки null or not present, но вот not null там не поставишь. Пришлось изгаляться с вариантом if var is null then end else blah-blah-blah. Тоже не добавило радости, если честно.

@музыка: Ryan Farish - Perfect Clarity

@темы: Scripting, Этот безумный мир

22:50 

Orphan Virtual Machines

Stance Dance
Если в нескольких словах - понедельник вышел жестким.
Вводная - прийти на работу, зная, что висит одна из виртуальных машин (несчастный линукс на CentOS), на пинг не отзывается, бекап с нее, соответственно, не идет. Рестарт и можно спокойно разбираться, что не так. Раньше, чем успел послать ей команду перезапуска М. произносит: "Странно, к коммуникатору не могу подцепиться..." (Коммуникатор = Office Communications Server).
- Да ну нафиг! не знаю ничего про коммуникатор, знаю только про зависшее "зеркало" (та самая виртуальная машина).
Открыть VI Client, окинуть взглядом список машин, убедиться, что все в статусе Running, перейти в консоль коммуникатора, и охренеть на месте:
Virtual machine config file does not exist
Так, стоп. Машина есть, она зарегистрирована, она запущена. Так как же? Тыкаюсь в то самое "зеркало" - перехожу на ее консоль, и получаю абсолютно то же сообщение. ОК, берем наугад третью машину, переключаемся в ее консоль, заранее зная, что получим в ответ. Остается последнее: выбрать хост esxi, перейти на вкладку конфигурации, щелкнуть Storage. Формально все на месте. Видна арена, два раздела. Нажать Rescan и подтвердить худшие опасения - СХД с виртуальными машинами не видна вообще.
Надо сказать - это финиш. Бегом в серверную, открыть дверь, и понять, что же на самом деле не так. А все банально - в серверной жарковато.
Чуть позже подтянулись еще люди, от которых и узнали мы, что в воскресенье тут в очередной раз возникла нештатная ситуация с системой охлаждения и с электропитанием. Последнее наши "железные кони" выдержали - UPSы вытянули их. А вот отсутствие охлаждения - это труба. СХД, державшая на себе весь "запас" виртуальных машин, не выдержала перегрева и "замкнулась в себе", перестав отвечать на любые запросы по любым интерфейсам. В том числе и по Fiber Channel.
Делать нечего. Рестарт СХД. Долгих несколько минут, после чего Rescan на хосте esxi. СХД послушно появилась на месте, хост снова увидел все нужные разделы. Поочередный рестарт всех виртуальных машин, и работа нормализована.
Дальнейшее уже не столь интересно - ревизия бекапов (на всякий случай), да просто огромные волны ненависти в адрес администрации бизнес-центра.

@музыка: Corvus Corax - Avanti, Najo Ratte

@темы: Этот безумный мир

22:09 

PCI DSS

Stance Dance

Original @ ServerFault.com.
Перевод истории на Хабрахабре.
Читать всем, даже если вы не имеете никакого отношения к аудиту платежных систем и процессинговых центров. Это феерия.

@темы: Security, Этот безумный мир

22:55 

Trend Micro Office Scan Client 10.5

Stance Dance

По непонятной причине стоящий на файлопомойке клиент корпоративного антивируса отцепился от управляющей консоли. Offline режим, и все тут. Принял решение его переустановить, хотя и помню об замечательной утилитке IpXfer, которая и нужна для переподключения клиента к другому серверу. Или тому же самому, как раз вот в таком случае.
Сказано, сделано, команда на удаление отдана. В процессе видно, что удаление происходит с ооочень большим скрипом, удаление служб продолжалось минут 15, на стадии удаления файлов система воткнулась еще на 40 минут. Все симптомы зависания. Делать нечего, распечатывается специальный документ, и пошагово проходим процедуру ручной очистки системы. В конце этого списка значится - reboot. Ясное дело, что боевой файловый сервер перезагрузить в течение рабочего дня никто не даст, значит, откладываем это дело до вечера, команду на рестарт можно отдать и из дому.
Перезагрузили. С радостным лицом поставили клиент заново и... поняли, что что-то пошло не совсем так, как надо.
"Все вышло не так, как ты планировал, Итэн..." (с) M:I:2
Вместо трех нужных служб в системе зарегистрированы только две. Более того, служба сканирования в реальном времени запускаться отказывается в принципе, ссылаясь на то, что ей нечего делать(!). И вспоминаем, что до повторной установки нужно было все же вынести старые каталоги антивируса. Дурная голова ногам рукам покоя не дает. Ладно, снова сносим антивирус, и ожидаемо получаем затык на стадии удаления файлов. Что ж, взглянем на этот процесс под микроскопом, то есть Process Monitor'ом, по критерию:
Process Name is NTRMV.EXE
Результат следующий - данный процесс вовсю елозит по папке C:\Program Files\Trend Micro\Office Scan Client\Hlog, открывает файл, пишет в него, закрывает.
Что ж это за логи такие? Залезаем в папку проводником и получаем зависший проводник. Снять процесс, попробовать пролезть другим шеллом. Получаем то же самое. Ладно, расчитай мне размер этой папки. Explorer.exe уходит в подсчеты, отгребает на себя гигабайт оперативной памяти, но результат удручает - найдено 0 объектов. К слову сказать, ни TC, ни cmd в этом плане тоже не отличились. Что же делать? Это логи, они находятся в папке, которая полностью предполагается к сносу. Их надо снести. Прпробуем метод, который меня еще не подводил:
cmd
cd c:\program files\trend micro\officescan client
del /f/s/q hlog\*.*
После минутного раздумья шел все же начал удалять все то, что там было. Тогда я еще не знал, сколько там всего.
Через минут 20 этого терзания диска я остановил процесс и попробовал снова зайти туда проводником. Увиденное повергло меня в шок. Проводник все же смог показать часть этого каталога: 300000 объектов, каждый размером меньше килобайта. И это - еще не весь каталог. Ну что же, повторный запуск удаления всего и вся через командную строку и ждать результатов. Это надолго...
P.S. Поймал себя на мысли, что это уже не первые боевые действия с данным антивирусом. Связка Trend Micro и Symantec Backup Exec уже показала себя во всей красе.

@музыка: KOTO - Die Klapperschlange

@темы: Security, Viruses and Spam, Этот безумный мир

00:24 

Largest mailbox ever seen...

Stance Dance
Вот задумайтесь, какой самый большой почтовый ящик (электронная почта) вам приходилось в вашей жизни видеть? Вот что довелось узреть мне:

При условии, что число в третьем столбце - это не байты, а килобайты, становится страшно. А потом сотрудники удивляются, почему это Outlook начинает периодически показывать сообщение о том, что программа "пытается получить данные с сервера", и зависать.
Ах, да, мы же клиенто-ориентированная компания (просто клиентами для IT-отдела являются сами же сотрудники). Все для них, все ради них, все для их удобства. Если меня сейчас читает кто-то из руководящего состава какой-либо компании - мой вам совет: когда ваш системный администратор положит на стол проект по введению квот на почтовые ящики (если их еще нет), прислушайтесь к его словам. Это только по неопытности кажется, что предельные размеры ящиков - зло, на самом деле пользы от них намного больше, чем неудобства. Это не прихоть IT отдела, это суровая необходимость.
К слову сказать, после очистки от всего шлака, объем того ящика резко уменьшился до 1.2 Гб. Только вот на размер почтовой базы данных это не повлияет, к сожалению. Для уменьшения базы ее нужно дефрагментировать в offline-mode, а это полноее ее отключение где-то на полдня.

@музыка: Frank Borell - Wake Up in Paradise (Dream Spirit Mix)

@темы: MS Exchange, Этот безумный мир

02:31 

Войны с роботами

Stance Dance

А началось все с того, что стукнуло мне в голову посмотреть, не вышло ли новых прошивок для моего Ведроида. Сказано - сделано, LG Mobile Support Tool на старт, внимание, марш. Да, он запустился, попросил соединение с телефоном и... не нашел оного. Как так? Устройство на столе, USB хвост подключен и к нему, и к системнику. Порт заведомо рабочий, пару часов назад в нем жила флешка. Нет, нету у тебя устройства, дорогуша, вынь да положь.
Чем черт не шутит, переключаем хвост в другой порт. Та же история. Так, если устройство в ОС не видно, стало быть дело может быть в драйверах, ибо устройство как USB хард-диск видно и работает, но оно же "Composite USB device". Не беда, драйверы все в наличии. Сносим текущие, ставим посвежее. Как уже можно догадаться - результат тот же. Ну черт с тобой, VMWare на старт, внимание, марш. Свежая VM, подключаем устройство туда. Неа, нету у тебя устройства, дорогуша, вынь да положь. Ну что за напасть...
К слову сказать, LG PC Suite отличился ровно тем же, устройства просто нет. Ладно, перезагрузка трубки, попытка подключения... тот же эффект.
Начинаем прикидывать. Вся информация дублирована в облаке (контакты, фото). Все программы, которые там стоят, можно и переставить, и довольно быстро. Устройству делается Factory Reset.
После этой весьма и весьма жесткой процедуры робот весело мигает сообщением о том, что он у нас базируется на Android 2.3.3. Это уже хорошо, потому что изначально LGP500 работает на версии 2.2, прошивку 2.3 ждали очень долго и мучительно. Подключаем к USB хвосту, и о, чудо! Девайс прекрасно обнаруживается! Ладно, отставляем это дело, проводим первоначальную настройку телефона. Добавить Google-аккаунт, вычистить все от ненавистных ярлычков на контакт, одноклассники, янедкс- и гуглопоиск и тому подобного барахла. Поставить все необходимые мне ярлыки, настройки... После всей этой косметической оттделки можно и софт докидывать. Вход в Маркет, выбор первого из нужных приложений, установка. Все отлично. Докидываем половину из оставшихся и вспоминаем, что через веб-сайт на ПК это делать несколько удобнее. Заход в Android Market на компьютере, выбор нужного приложения... а дальше челюсть пробивает пол до фундамента: "У вас нет подходящего Android-устройства для установки данного приложения". Это уже за гранью понимания. Проверяем список устройств и понимаем, что там пусто. Простите, а где все? Где все ранее (в марте месяце) установленное? Ну хорошо, даже если был сделан хард-ресет, и после оного информация с аккаунта Google удаляется, уже сейчас как минимум три программы должно светиться, и сам телефон - тоже. Нет, нифига, говорит нам гугл, нет у вас телефонов. Идите в магазин, купите, активируйте, тогда я может быть чего-нибудь и покажу. Ах ты ж зараза.
Лезем в справку, читаем - для того, чтобы телефон появился в списке устройств на сайте, необходимо зайти в Маркет с этого телефона, авторизоваться в нем, а затем уже зайти на сайт на ПК, введя тот же логин и пароль, под которым авторизовался в Маркете на телефоне. Проклятие и еще раз проклятие, все это было сделано!
Ладно, нам не привыкать! Второй Hard-reset. Только на этот раз учетку Google подключаем уже после того, как об этом попросит Маркет. Ввели, авторизовались. Даже поставили одно из нужных приложений. Лезем на сайт, в списке устройств ноль. Да твою ж... материнскую плату! Обновить страницу и с удивлением обнаружить, что телефон наконец-то опознан сайтом, но без этого самого приложения. Да и фиг с тобой. Уже через сайт добавить все необходимые программки, удостовериться, что они появились в списке установленных и со спокойной душой закрыть Маркет.
Можно приступать к обновлению самого ПО телефона (да, я знаю, что вообще-то делается наоборот). В этот раз LG Mobile Support Tool отрабатывает на ура, прошивка меняет свою букву в идентификаторе на актуальную. Для успокоения души прогоняется поиск обновлений еще раз, после чего эта самая душа офигевает, ибо найдено еще одно обновление. Ну что ж, как работает, например, WSUS, известно, некоторые обновки ставятся сугубо последовательно, так что ставь. LG Mobile Support Tool проверяет соединение с телефоном, после чего говорит, что данное обновление этим телефоном НЕ ПОДДЕРЖИВАЕТСЯ! Да твою ж... материнскую плату дважды!!! А хотя бы написать, что это за обновление, бывает? Нее, не бывает, вот вам ссылка на сайт LG - разбирайтесь сами. Сволочь. На это у меня уже сил не хватило.
В течение всех этих разборок рядом сидел товарищ, любитель яблочных огрызков, подкалывали друг друга, чтоб не так уж паршиво было. "А вот у нас в Секте...", "Да ну вас, у нас, робототехников, веселее". И все в таком духе.

Какие выводы можно сделать из всей этой истории? За всю свою жизнь у меня было два телефона, способные общаться с ПК. Это Benq-Siemens S68 (он лежит до сих пор, как резервный), и я считаю его идеальным для себя аппаратом; и Ведроид, который был взят из-за функционала. Я не жалею о том, что связался с Android, но вот такие казусы все же портят впечатлений от платформы. И тут уже даже не знаешь, это вина платформы или производителя самого устройства, в данном случае LG. Но по крайней мере я знал, что на Google-платформе такое возможно. А ведь есть еще огромное количество людей, которые берут андроидов только из-за того, что это массово, по принципу - у Васи есть, стало быть он крут, а я чем хуже. Люди, перед покупкой все же читайте материалы о том, что именно вы покупаете. Или все же порасспрашивайте знакомых знающих людей о плюсах и минусах такой покупки.
И еще одна претензия - это ПО для связи мобильника и ПК. Почти ни один из известных мне производителей (известных мне - читать как марки, прошедшие через мои руки) так и не смог написать вменяемое программное обеспечение для связи этих устройств в Windows. Почти. Единственный, кому это удалось (да, я знаю, что сейчас полетят помидоры) - это Microsoft. ActiveSync, конечно, тоже не без нареканий, но все они сводятся лишь к тому, что в случае возникновения ошибки по ее коду мало, что скажешь. Зато в процессе работы и настройки все просто супер. Лаконично, просто, понятно. Остальные же... куча мастеров, которые не нужны вовсе. Интерфейсы явно были написаны в состоянии измененного сознания (ну а как же без выпендрежа в наши-то дни, когда всем правит маркетинг). Да дьявол с ними, с интерфейсами, даже свою прямую обязанность: связь двух устройств, это самое ПО далеко не всегда выполняет так, как надо. Чего уж говорить обо всем остальном...

@музыка: Galaxion - Aftershock

@темы: Android, Этот безумный мир

21:02 

Войны с роботами #2

Stance Dance

Когда-то доводилось мне писать о весьма удручающем баге в Android-телефонах - отсылка СМС не тому получателю. Ради интереса залез в этот тред посмотреть, чего нового написано. В самом конце оставлена пара записей от куратора этого сайта (судя по всему). Вот они, что называется, без купюр:
Comment 1820 by jrobbins@google.com, Jun 23, 2011
I'm going to block further comments on this issue because it is suspected of placing excessive load on one part of our server-side software for Google Project Hosting.


И вторая (видать с правами что-то не то было):
Comment 1821 by jrobbins@google.com, Jun 28, 2011
Corrected permissions to just block additional comments because of server load.


Мир должен знать своих героев!
Читаем статус этого треда:
Status: Released
Owner: n...@google.com
Closed: Jan 2011
Type-Defect
Priority-Critical
Version-2.2
ReportedBy-User
Restrict-AddIssueComment-Commit

Google, огромное спасибо за такую дезу, но факт остается фактом, в прошивке 2.3.3 этот баг сохранен и так же хорошо воспроизводится, как и раньше.
Печально. Очень печально, что такая крупная, и вроде как уважаемая компания не удосуживается дать хоть какую-то обратную связь.

@музыка: Galaxion - Sleeping Beauty

@темы: Android, Этот безумный мир

22:20 

Task Manager vs Process Explorer

Stance Dance
Если кратко, то первый - это анахронизм уже во времена Windows XP. Абсолютно неинформативен и даже вреден. В 2008, Windows 7 уже появился вменяемый Resource Monitor.
А полностью история выглядит так. Есть корпоративный антивирус, имя которому Trend Micro Office Scan 10.5. Да, да, кто "в теме" - тому уже все ясно. Есть система наблюдения за состоянием серверов, которая исправно докладывает в контрольной панели о том, что на каком-либо хосте нештатная ситуация. Как и сегодня - на одном из серверов зарегистрировано расходование огромного количества памяти. Свободной осталось пара процентов, а это RODC, который таким никогда не страдал. Открываем Task Manager - тишь и благодать. Но ведь свободной памяти нет... Открываем любимый Process Explorer и видим прекрасное:

Особое внимание на процесс TmListen.exe. Это мелкая служба, задача которой принимать команды от сервера Trend Micro. Второй столбец - это объем памяти, который данная служба сейчас действительно занимает в RAM. Первый же - сколько эта служба подгребла под себя за все время своей работы. Тут и RAM, и Page File. Полтора гигабайта. Служба, которая просто принимает собщение от центра контроля, и больше ничего. У меня просто нет слов.
А самое противное, эта утечка памяти проявляется не только на одном сервере, а практически на всех компьютерах, где стоит клиент TM, а стоит он, по понятным причинам, везде. Рабочие станции спасает тот факт, что они все же перезагружаются. Постоянно работающие же серверы - под ударом. Лечение простое - Unload Client, Run Client. И до следующего раза, который будет где-то месяца через два.

@музыка: Lifescapes - Awakening

@темы: Этот безумный мир

Записная книжка

главная