Yet Another Conference 2012

На днях я ездил в Москву на YaC'12 - конференцию организованную Yandex. Эта конференция содержит несколько секций интересных для системных администраторов. Среди прочего на конференции были затронуты облачные технологии, администрирование, безопасность и сетевые технологии.

Особенно запомнились следующие выступления:

- Доклад от Parallels про CRIU.
- Доклад от Yandex про балансировку с помощью IPVS.
- Про внедрение IPv6 в Yandex.

Эти доклады сделали мою конференцию. Если вы не ездили и интересуетесь системным администрированием, то крайне рекомендую посмотреть их в записи, когда они станут доступны.

Кроме этого я присутствовал еще на нескольких выступлениях: про выбор базы данных в Nebula, про Illumos, про System Administration Automation in High Scale и про OpenFlow. Некоторые из них меня просто обескуражили, а от некоторых меня просто трясло от гнева.

- Про Nebula: они сравнили Cassandra 1.0.0, MongoDB 2.0.0 и Postgres неизвестной версии. Одним из главных требований была поддержка устойчивых схем из каробки. Поэтому они реплицировали базу PostgreSQL с помощью DRBD!!! Когда я спросил что за версию они использовали в тестировании, докладчик не смог мне ответить. Насколько я понял из объяснения это была достаточно старая версия, скорее всего до 9.0. Т.к. они ничего не слышали о streaming репликации PostgreSQL :( Кроме того, лучший способ ускорить PostgreSQL - это обновиться на последнюю версию. Не мудрено, что PostgreSQL у них вообще не прошел тесты... В-общем, одно расстройство, а не доклад.

- Illumos: галопом по технологиям-кофеткам OpenSolaris типа zfs, dtrace. Немного об облачных решениях на базе Illumos: Joyent SmartDataCenter и NexentaStor Маловато конкретики и выступление сильно отдавало рекламой.

- Турецкий товарищ выступил с рассказом в стиле Капитана Очевидность: повторил то, что должно быть известно опытному системному администратору. Впрочем может это только мне нерелевантно оказалось. Хорошо, что я встретил Игоря из Skype (Qik) мы обсудили с ним новости из Chef-мира: кто с чем и как поработал в последнее время.

- рассказ про OpenFlow был более чем ужасен. Выглядело это так: TCP - гавно, поэтому управление сетью мы вынесем на отдельный узел, создав point of failure. Ну и фиг с ним, зато посмотрите какая замечательная академическая задача, не имеющая к реальной жизни никакого отношения. Пожалейте свои нервы, не смотрите это выступление. Лучше прочитайте, что такое OpenFlow на самом деле на ACM от того самого Томаса @yesthattom Лимончелли. Я сам еще не читал, но уверен, что Томас + ACM стоящее сочетание. Оно у меня недалеко в очереди на чтение.

О плохих докладах я написал несколько больше, чтобы вы не тратили на них свое время. Поверьте на слово, оно того не стоит. А доклады, которые я упомянул в начале, очень хорошие. Крайне рекомендую. Говорят было еще несколько интересных докладов в других секциях. Я на них лично не ходил, отзыва не дам. Планирую посмотреть в записи как появятся.

Из замечательного кроме интересных выступлений: я подержал за руку живого Bobuk'а и передал ему подарок от наших ребят - футболку Ecwid. Bobuk вел секцию в первом зале и я посчитал, что не стоит его долго теребить. А по дороге назад в Ульяновск я таки дослушал последнюю запись Radio-T и узнал, что он наоборот призывал всячески себя теребить и общаться. Жаль, что не послушал это по дороге на YaC :(

В целом впечатление от конференции очень положительное. Были очень интересные доклады, было достаточно общения, повидал друзей, познакомился с новыми людьми. На следующий день сходил на экскурсию в офис Яндекс, тоже друзей навестил. Одного из них два года не видел. Хороший офис, аккуратные серверные :) Вот фоточек немного осталось.

Сортировка хэша по свойствам хранимых в нем объектов

Chef-party в Ульяновске

23 Июня в Ульяновске состоялась первая вечеринка, посвященная Chef. Если кто не знает, это такой мощный инструмент для управления конфигурациями серверов, который позволяет превратить конфигурацию сервера в код и использовать этот код для запуска новых серверов. Я для себя определяю применение инструментов для управления конфигурацией как "Системное администрирование 2.0". Не важно, что выбрал ты Puppet или Chef, любой из этих инструментов выводит тебя на следующий уровень.

Поводом для встречи послужил приезд Ивана Евтуховича в Ульяновск, чем поспешил воспользоваться Кирилл. По опыту Ulcamp::dev встреч, Chef'ом в Ульяновске интересуется два с половиной калеки, а применяют в жизни и того меньше. Я помню две попытки рассказать про Chef в Ульяновске:

• на одной из встреч Ulcamp::dev тот же Кирилл рассказывал;
• на Стачке о Chef'е рассказывал Александр Титов .

В обоих случаях я не наблюдал особого понимания со стороны слушателей. Поэтому я был слегка удивлен, что вчерашнее событие собрало около 20 человек! Вообще встреча собрала представителей Kaize, Tulp.ru, Undev, Echo и Ecwid.

Когда Кирилл стал искать, где можно собраться двадцати инженерам и по-занудствовать о смысле жизни об инструментах в пятницу вечером, стало ясно, что выбора особого нет... Тогда я поговорил с нашим CEO Русланом и у нас появилось место для проведения встречи - Штабквартира Ecwid :)

Что мне запомнилось из встречи?

• Мы обсудили кто как разделяет разработку cookbook'ов от продакшена. Например, мы используем окружения, а Витя использует разные рецепты внутри одной версии cookbook'а;
• Немного по-пиннали CouchDB за прожорливость.
• Я рассказал о моих впечатлениях Why's (poignant) guide to Ruby , о том насколько повредило мою психику чтение этой книги. Оказалось никто из товарищей рубистов не читал это произведение и я один теперь мучаюсь с необратимыми повреждениями коры головного мозга :) Я всячески их убеждал, что это просто must read какое художественное произведение, чего только стоит Dr. Cham, улетевший на табуретке на другую планету...
• Я рассказал о том как пилят Chef-сервер на Erlang'е. Этому был посвящен один из недавних эпизодов  Food Fight Show . Как выяснилось кроме меня никто не слушает этот достойнейший подкаст :( Пичаль... Это просто кладезь полезной информации о Chef.
• Рассказал о куче полезной информации, которую можно получать в пассивном режиме из списка рассылки Chef, и о том, как мне быстро помогли на канале #chef в IRC Freenode.
• Мы расспросили Александра Грушина об их опыте работы с Puppet в Echo. Саша говорит, оно просто работает и пилить ничего пока не приходилось. А вообще по его словам, самая большая проблема - это осознание, что управление конфигурациями необходимо. Я с ним полностью согласен, а когда ты начинаешь это делать, у тебя возникает вопрос: "КАК я жил раньше без этого! Это же закат солнца вручную (с)!" Было очень интересно послушать как обстоят дела с Puppet'ом, потому что из собравшихся с ним практически никто не работал.
• Мой напарник, Владимир, по-расспрашивал кто и насколько глубоко заглядывал в исходники Chef'а. Поделился идеей, что о качестве продукта можно узнать многое, если заглянуть в код. Поделился опытом копания в ранних версиях Postgres.
• Обсудили Postgres и доступные способы репликации. Иван Евтухович рассказал о своем опыте со streaming-репликацией в Postgres 9. Обсудили репликацию на дальние расстояния. Пришли к выводу, что для больших расстояний подходит либо WAL-based либо Trigger-based репликация.
• Уже перебравшись в Дубнин я по-рассказывал о Chefconf, о качестве выступлений и доступности их на Youtube-канале Opscode. Показал оставшимся ребятам шутку от Atlassian о парном программировании.

Вообще говорили много и о разном. К сожалению, лично я не почерпнул много нового для себя :( Лишь подтверждения некоторых своих мыслей. Жаль конечно, но надеюсь то что рассказывал я было интересно и ново другим участникам встречи...

И еще в самом конце когда уже шли по машинам кому-то обещал дать ссылку на список подкастов, которые слушаю.

Спасибо всем, кто пришел на встречу. Надеюсь она была вам полезна.

Установка fuse под Mac OS X

Fuse позволяет реализовывать файловые системы на уровне пользователя (user space).

Установка с помощью brew:

$ brew install fuse4x
$ sudo cp -rfX /usr/local/Cellar/fuse4x-kext/0.9.0/Library/Extensions/fuse4x.kext /System/Library/Extensions
$ sudo chmod +s /System/Library/Extensions/fuse4x.kext/Support/load_fuse4x

Проверка:

$ sudo kextunload /System/Library/Extensions/fuse4x.kext/
$ sudo kextload /System/Library/Extensions/fuse4x.kext/

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

$ sudo vim /Library/LaunchDaemons/com.apple.fuse4x.plist


$ sudo launchctl load -w /Library/LaunchDaemons/com.apple.fuse4x.plist

Подкасты, которые стоит слушать.

Я живу недалеко от офиса, примерно в 3-х километрах. И несмотря на то, что могу спокойно работать из дома, я предпочитаю ходить в офис. Тому есть несколько причин. И одна из причин: пока я иду на работу, я могу послушать что-нибудь клевое :)

Я начал ходить в офис пешком зимой 2010-го. В то время у меня обнаружились небольшие проблемы с сердцем и где-то я вычитал, что пешие прогулки укрепляют сердечную мышцу. Да и Ворон как раз рассказал, что ходит в офис пешком (а ему на километр-полтора дальше идти). У меня тогда не было свободного графика, в офис я должен был приходить обязательно и не позже 9-ти. Я подумал: "Хм, я же так двух зайцев убью. И до офиса доберусь вовремя, и сердечко подкачаю..." Прогулка в офис занимает 30-40 минут в зависимости от погоды и насколько я угадал с одеждой. Сначала я считал, что смогу в это время планировать рабочий день и обдумывать задачи. Но это не очень получалось и я стал искать как использовать, чем занять мозг на время прогулки. Попробовал просто слушать радио или музыку: да мозг занимает, но бесполезно. Потраченное время было жалко...

Как раз в то время Сергей Булаев писал, что слушает Рунетологию по дороге в офис. Заинтересовался, скачал на телефон. Попробовал слушать во время прогулки до офиса. Понравилось. Так я узнал, что существует Рунет :) и в нем, оказывается, происходит какая-то движуха. В силу специфики работы практически не пользуюсь рускоязычным интернетом: актуальная информация практически вся в англоязычном сегменте. В то время Рунет для меня заключался в паре соц. сетей, в которые я изредка заглядывал, в Яндекс.Маркете и, позже, Яндекс.Музыке...

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

Итак, я крепко подсел на подкасты. Я пробовал много разных шоу. В силу специфики работы в моем плейлисте осталось мало русскоязычных подкастов. Ограниченность времени, которое я могу потратить на подкасты, привела в жесткому отбору действительно интересных для меня шоу. Ниже я привожу список подкастов, которые я считаю достойными внимания. Они отсортированы по убыванию моей любви к ним.

1. Radio-T. Один из немногих подкастов на русском языке, которые стоит слушать. Umputun, Бобук, Грей и Маринка собираются по субботам в 11 вечера, чтобы обсудить события из IT-мира. В первую неделю месяца выпуски отличаются особой "гиковостью", когда ведущие не стесняются в выражениях и заглядывают в самые дебри технологий и методологий. В-общем, первый выпуск месяца самый ми-ми-мишный.
2. UWP - Еженедельный подкаст от Umputun. Личный подкаст от того самого Umputun'а, который живет где-то на чикагщине и иногда рассказывает о своей жизни. Вещает самозабвенно, так что оторваться невозможно. Слушать для успокоения души три раза перед сном. Также периодически выкладывает душеуспокоительные видики поездок на своем Хамере. Не дайте ввести себя в заблуждение названию, неделя Umputun'а запросто может вмещать в себя несколько астрономических недель :)
3. The Foof Fight Show. Молодой подкаст, посвященный DevOps-движению в общем, и Chef с Ruby в частности. Ребята обсуждают самые разнообразные проблемы из мира Configuration Managment'а. В гости к основным ведущим постоянно приходят не менее интересные гости из DevOps-коммьюнити. Вообще, компания обычно собирается очень интернациональная. Среди прочего обсуждают последние изменения в кукбуках, что очень полезно, если вы используете chef ежедневно.
4. DevOps Cafe Podcast. Более другой подкаст, посвященный DevOps-движению. Крайний выпуск на данный момент (#24) был бесконечно шикарен, ибо обсуждались вопросы близкие мне лично. Впрочем, идеи, обсуждаемые в этом подкасте, часто знакомы мне не понаслышке. Стоит слушать постоянно.
5. The Changelog. Ведущие данного подкаста приглашают в гости разработчиков различных open source-решений. Уровень клевости выпусков сильно зависит от софта, который обсуждается. Кроме того ребята ведут интересный блог.
6. This Developer's Life. Подкаст посвящен различным сторонам жизни разработчиков. Очень редкий. Музыкальное оформление выпусков заслуживает отдельного упоминания. Лично я был особенно впечатлен выпуском "2.0.2 Pressure".
7. PaulDotCom Security Weekly. Безбашенный подкаст пентестеров, если вы понимаете о чем я :) Обычно выпуск состоит из двух частей. В первой они принимают какого-нибудь гостя, все идет спокойно. Ко второй части программы они догоняются алкоголем, иногда  тяжелым, и дальше обсуждают новости из своего пентестерского мира. С детьми слушать не стоит ;)
8. Security Now! Подкаст от Стива Гибсона и Лео Лапорте о безопасности. Обычно обсуждают последние события + Стив расхваливает свой SpinRite и рассказывает о чем-нибудь технологическом. Обычно бывает интересно. Например, из этого подкаста я узнаю, что происходит в MS-мире: чего и как поломали, чего залатали и т.п. Если вы только недавно начали слушать англоязычные подкасты, то этот вам подойдет, т.к. у соведущих очень хорошо поставлена речь. Сайт twit.tv периодически ломают, если Гуггл будет предупреждать, то загляните позже  ;)
9. The Art Of Programming. Рускоязычный подкаст о программировании. Голодный - ведущий подкаста - очень калоритная личность. Вещает из Иркутска, при этом периодически откапывает интересных собеседников с разных концов планеты. Делает дело с любовью, слушать приятно.
10. Packet Pushers Podcast. Подкаст от британских сетевиков-хардварщиков. Бывает перегружен терминами, но те выпуски, что понятны, обычно интересные. К сожалению, пока не послушаешь, не угадаешь... Особого упоминания заслуживает Mrs. Y,   она добавляет шарма всем выпускам, в которых участвует.
11. English as a Second Language Podcast. Подкаст от лингвиствов из "прекрасного Лос-Анджелеса". Идеально подходит для начинающих слушателей англоязычных подкастов. Состоит из пары диалогов в неделю и The English Cafe раз в неделю. The English Cafe с удовольствием слушаю до сих пор, если добираюсь.
12. ТиБиБо. Подкаст о музыке. Странный, очень редкий. Узнал о нем благодаря Бобуку. Подкаст открыл мне творчество Вени Д'ркина и еще пары сильных голосов. Слушать для расширения сознания без химических средств.
13. Escape Pod и PodCastle. Новые для меня подкасты, в которых зачитывают небольшие фантастические (и фэнтези соответственно) произведения различных авторов. К сожалению, моего английского часто не хватает, чтобы наслаждаться произведениями в полной мере. Понятность рассказа сильно зависит от языка автора. Если автор не выпендривается в описаниях, то понять можно. В целом, уровень усвоения мной рассказов я оцениваю от 20-ти до 80%. Есть куда расти и это радует.

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

Сортировка по данным в анонимном хеше

Задача: отсортировать данные разнесенные по множеству серверов Postgres.

С ходу придумал два решения:

1. Собрать данные скриптом и обработать.
2. Написать server side функцию, которая установит dblink-соединение со всеми необходимыми севрерами, прогонит запрос по ним и вернет агрегированные данные. Необходимый запрос передается параметром.

Решение задачи первым методом:

Есть небольшая сложность: полей данных более, чем два. В случае C я бы использовал структуры. Но в Perl нет структур в комплете (хотя можно подобрать модуль). Я предпочел складывать данные ссылкой на анонимный хеш в хеш ( переменная %result ) :) Правда потом немного сложно сортировать эти записи. Собственно поэтому и пишу пост, магия сортировки происходит в третьей с конца строке:


Решение вторым методом пока не реализовывал. Сделаю - дополню пост.

Облака: выдумки маркетологов или реальность?

Представляю вашему вниманию текст моего выступления на Ulcamp 2011.

Сейчас "облака" - это один из мировых трендов. Только ленивый сейчас не говорит об "облаках". И если какой-то маркетолог не говорит про "облака", то это наверное мертвый маркетолог :) Мы же, хотим рассказать про "облака" с точки зрения сервиса, который реально их использует, которым пользуются больше 70 тысяч пользователей. Мы хотим показать вам "грязную", "неприкрытую" подноготную облаков.

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

И, да. Все это есть в "облаках". До появления облаков нужно было покупать лицензию на каждую машину. Теперь есть "облачные" решения: Google Docs, Gmail, Autocad WS. Появилось много решений, не имевших аналогов ранее: Dropbox, Yammer, Juniper Junosphere.

"Облака" делают более доступными программные продукты, которыми раньше мы не могли пользоваться из-за стоимости или технической сложности. Сравните сложность внедрения shopping cart-решения в существующий сайт до появления Ecwid и теперь. Яна Франк отлично описала свои "приключения".

Однако, "облака" - это прежде всего техническое решение, не маркетинговое. На самом деле, каждое "облачное" решение индивидуально. Начиная от механизмов виртуализации серверов (XEN, VMware, Jail) и заканчивая всем спектром SaaS решений.
Даже сами "облака" бывают разными:

- Infrastructure as a Service ( IaaS ) - это облако предоставляющее инфраструктуру. Вы нажимаете несколько кнопок, и у вас появляется полноценный сервер. Делаете запрос по API, и вас появляется еще десяток абсолютно таких же серверов. Красота!
Примеры: Amazon Web Services, Rackspace Cloud Services, GoGrid Cloud Hosting.

- Platform as a Service ( PaaS ) - это облако, которое дает вам платформу. Вы просто пишете программу в соответствии с предопределенными правилами, нажимаете кнопку “Deploy” и она живет дальше сама. Платформа обеспечивает ее работу за вас.

Примеры: Google App Engine, Echo StreamServer, Heroku, Azure Services Platform.

- Software as a Service ( SaaS ) - это законченный сервис. Если предыдущие решения используют разработчики, то эти работают с обычными пользователями.

Примеры: Ecwid, Google Docs, Gmail, Dropbox, Yammer, Autocad WS, Juniper Junosphere.

Когда вы говорите об "облаках", пожалуйста, уточняйте какой из “aaS” вы имеете ввиду :) Потому что SaaS Ecwid живет в IaaS Amazon EC2. Облако живет в облаке. Нам еще остается как-нибудь с Echo StreamServer’ом интегрироваться и полный набор облаков получится :)
Да, снаружи они тоже выглядят красиво, и даже блестяще. Но, вся "облачность" ограничивается их архитектурой. Об этом маркетологи, обычно умалчивают - зачем стеснять обывателей?

Например, Ecwid до недавнего времени хранил изображения продуктов на своих серверах. Представьте, у вас есть сервер, на котором хранятся картинки клиентов. Жесткие диски на сервере имеют конечный размер. Угадайте, насколько безразмерной является возможность заливать изображения продуктов? Да, все эти вопросы решаемы либо автоматизацией, либо изменениями в архитектуре. В данном случае не было архитектурных изменений, пока у нас не накопилось 5,5 миллионов картинок. Теперь картинки благополучно живут в безразмерном вместилище Amazon S3.

К чему это я? К тому что, обычно, за красивыми словами об автоматической масштабируемости обычно скрывается труд инженеров, которые ищут оптимальные решения в нашем мире ограниченных возможностей.

К слову о доступности. Что бы вам не обещали маркетологи, все "облака" работают на реальном железе. И, вы не поверите! Железо иногда "умирает"...

Возьмем пример: Amazon EC2. Известный IaaS сервис. Нажал кнопку - получил сервер. Однако, этот сервер работает на каком-то реальном, физическом железе. Что произойдет, если этот физический сервер умрет? Правильно, умрет и ваш хост. Да, инженеры Amazon мониторят железо, и да если железо умирает, то они скорее всего могут прозрачно переселить вас на другой хост. Если успеют. На моей памяти, сервера на Амазоне умирали навсегда несколько раз. Ваши действия в этом случае зависят от архитектуры: один сервис “не заметит” пропажи сервера, а у другого будет частичная недоступность, третий будет лежать целиком и полностью...

А что если умирает не хост-система, а сетевое оборудование? 21-го апреля 2011 года во время сервисных работ с сетевым оборудованием, основной поток трафика был ошибочно перенаправлен на вспомогательную сеть. Эта ошибка вызвала каскадное падение нескольких сервисов. В том числе сервиса, отвечающего за предоставление жестких дисков (Amazon EBS).  Множество серверов в этом регионе Амазона не было доступно в течение трех дней! Во время этого фейла лежала целая пачка известнейших сервисов. Вот замечательная коллекция сообщений о недоступности достаточно известных сервисов, затронутых тем несчастьем. Вот так "облака" опускаются на землю... Нам тогда повезло - нас не задело. Сервера падали вокруг, а мы счастливчики.

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

Далее. Есть такой сервис как Amazon S3, который позиционируется как мегаофигенное хранилище. Только они могут себе позволить упасть на 20 минут, именно столько были недоступны те самые картинки продуктов в Ecwid незадолго до этого выступления.

"Облака", вообще в последние годы стало модным словом. Все хотят быть "облачными". Даже последний VPS-провайдер не стесняется называть себя “облачным хостингом”. Хотя единственное, что он умеет делать - это давить ресурсы на хост-системе, чтобы засунуть побольше серверов на одно железо. А потом торжественно приоткрывать кран и называть это “облачным выделением ресурсов” :)

Такой спрос на “облачность” обесценил само понятие. Когда мне говорят про очередное “облачное” решение, я спрашиваю в чем заключается его "облачность". Давайте оставим право говорить об "облаках" маркетологам. А мы будем называть технологии своими именами.



Спасибо за внимание.

Деление текстового файла по шаблону

awk '/PATTERN/{i++}{print > "file.out."i}' file

А еще можно воспользоваться утилитой csplit из coreutils. Последний способ намного более удобен :)

CA сертификаты в Perl-скриптах в Debian

Если ваш скрипт внезапно перестал корректно соединяться с серверами по https и начал возвращать что-нибудь вроде этого:

error: 500 Can\'t connect to www.google.com:443 (certificate verify failed)';
Can't connect to www.google.com:443 (certificate verify failed)

LWP::Protocol::https::Socket: SSL connect attempt failed with unknown errorerror:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed at /usr/local/share/perl/5.10.1/LWP/Protocol/http.pm line 51.

Это вполне может означать, что клиент больше не знает где искать CA сертификаты. Помогите ему, подскажите, где искать. Добавьте:

$ENV{HTTPS_CA_DIR}="/etc/ssl/certs";

Как создать раздел на весь диск?

Подобное может понадобиться в скрипте. Итак, создать раздел на весь диск размером можно следующей командой:

/bin/echo ",,," | /sbin/sfdisk -L /dev/sdX

Восстановление MyISAM таблиц при восстановлении раздела из снапшота

Оставлю здесь, путь лежит

find /$PATH/db/ -name "*.MYI" -exec myisamchk --silent --force --fast --update-state {} \;

JOIN по нескольким таблицам.

YAML в perl'отворчестве

Задача: вы пишите большой perl-скрипт, который должен выполнять длительные/рутинные операции. Вы взрослый мальчик и не боитесь CPAN. Вы используете самые вкусные модули, которые помогают вам писать быстро и без изобретения велосипедов. Некоторые длительные операции порождают объекты (да, вы совсем взрослый мальчик), с которыми вы и работаете дальше.

Проблема: Чем длительнее операции, которые выполняются скриптом, тем больше времени вам требуется чтобы отладить скрипт... Например, скрипт добирается до места отладки только через 15 минут. А если при этом каждый раз выделяются значительные ресурсы?

Решение: Сериализация/десериализация объектов.

В частности, мне подошла реализация YAML из модуля (Хотя тут поговаривают, что JSON захватит мир...)

Достаточный минимум:

use YAML qw(DumpFile LoadFile);

DumpFile('object.yml', $obj);

my $obj = LoadFile('object.yml');

Противная ошибка в Crypt::DES

Проблема: При использовании модуля Net::SSH::Perl при попытке выполнения некоторых команд в $ssh->cmd() можно получить следующюю ошибку:

input must be 8 bytes long at /usr/local/lib/perl/5.10.1/Crypt/DES.pm line 57.

Причина: модуль Net::SSH::Perl реализован на чистом Perl и все методы шифрования пользует свои, в том числе и Crypt::DES. А последний плохо дружит в UTF-8, поэтому и отгребает ошибку.

Фикс: добавить 'utf8::downgrade($data);' в проблемный DES.pm прямо перед строкой, на которую ссылается ошибка. Например, в мое случае я заменил

my ($self,$data) = @_;
return Crypt::DES::crypt($data, $data, $self->{'ks'}, 1);

на

my ($self,$data) = @_;
utf8::downgrade($data);
return Crypt::DES::crypt($data, $data, $self->{'ks'}, 1);

Решение нашел на perlmonks.org.

P.S. Та же беда с Cryprt::Blowfish. Фиксится так же.

P.P.S. Можно еще попробовать чиперы другие использовать. Я не пробовал.

Удаление триггеров bucardo в Postgres

Для сервисных нужд я иногда использую bucardo. Утилита внятная. Четкая документация. Работает и не жужжит :)

У нее есть одна особенность - она не удаляет триггеры из базы, даже если мы убираем ее из обработки. Это было бы не страшно, если бы лишние триггеры не замедляли работу базы. Поэтому для удаления bucardo-триггеров была написана следующая функция:


Исполнение, как обычно:

select strip_bucardo_triggers();

"Raising Elephants" mnemonic device

The section was removed from Wiki with the following comment: Removed section. I strongly feel it doesn't belong. There's no magic formula and REISUB doesn't seem like a good idea either.

I do not think so. So here is the removed section:

---
A common idiom to perform a safe reboot of a Linux computer which has otherwise locked up, the QWERTY (or AZERTY) mnemonic "Raising Elephants Is So Utterly Boring", "Reboot Even If System Utterly Broken" or simply remembering the word "BUSIER" backwards, is often useful. It stands for:

unRaw       
 tErminate 
 kIll       
  Sync     
  Unmount  
reBoot.

This can prevent a fsck being required on reboot and gives some programs a chance to save emergency backups of unsaved work.
In practice, each command may require a few seconds to complete, especially if feedback is unavailable from the screen due to a freeze or display corruption. For example, sending SIGKILL to processes which have not yet finished terminating can cause data loss.
---

Преобразование varchar в integer в Postgres на лету.

Для подобного преобразования достаточно определить следующую функцию:


Источник решения: stackoverflow.com.

Установка grub

Выдержка из документации по GRUB Legacy


Installing GRUB natively

Caution: Installing GRUB's stage1 in this manner will erase the normal boot-sector used by an OS.

GRUB can currently boot GNU Mach, Linux, FreeBSD, NetBSD, and OpenBSD directly, so using it on a boot sector (the first sector of a partition) should be okay. But generally, it would be a good idea to back up the first sector of the partition on which you are installing GRUB's stage1. This isn't as important if you are installing GRUB on the first sector of a hard disk, since it's easy to reinitialize it (e.g. by running `FDISK /MBR' from DOS).

If you decide to install GRUB in the native environment, which is definitely desirable, you'll need to create a GRUB boot disk, and reboot your computer with it. Otherwise, see 3.3 Installing GRUB using grub-install.

Once started, GRUB will show the command-line interface (see section 12.1 The flexible command-line interface). First, set the GRUB's root device(4) to the partition containing the boot directory, like this:
 
grub> root (hd0,0)

If you are not sure which partition actually holds this directory, use the command find, like this:
 
grub> find /boot/grub/stage1

This will search for the file name `/boot/grub/stage1' and show the devices which contain the file.

Once you've set the root device correctly, run the command setup (see section 13.3.34 setup):
 
grub> setup (hd0)

This command will install the GRUB boot loader on the Master Boot Record (MBR) of the first drive. If you want to put GRUB into the boot sector of a partition instead of putting it in the MBR, specify the partition into which you want to install GRUB:

grub> setup (hd0,0)

If you install GRUB into a partition or a drive other than the first one, you must chain-load GRUB from another boot loader. Refer to the manual for the boot loader to know how to chain-load GRUB.

Наращивание swap-памяти.

К счастью подобное может понадобиться редко. Но иногда на машине начинает нехватать даже swap-памяти. В этом случае ее можно увеличить создав дополнительный файл подкачки.

Создаем файл нужного размера:
# dd if=/dev/zero of=/mnt/swapfile bs=1024k count=3072

Подгатавливаем для использовения в качестве swap-файла:
# mkswap /mnt/swapfile

Подключаем в систему с нужным приоритетом. Чем выше значение, тем выше приоритет
# swapon -p 5 /mnt/swapfile

Переподключаем текущий раздел подкачки с более высоким приоритетом:
# swapoff /dev/sda3
# swapon -p 10 /dev/sda3

Правим /etc/fstab в соответствии с новыми реалиями (не забываем добавить параметр приоритета pri=):

---
/dev/sda3 swap swap defaults,pri=10 0 0
/mnt/swapfile swap swap defaults,pri=5 0 0
---

Посмотреть текущее состояние разделов/файлов подкачки можно следующей командой:
# swapon -s

Пассивный мониторинг

Ощущаю человека с номером +7-9510-98-89-08 родственником, ни или может другом. Ну в-общем человеком небезучастным.

Помню года 3-4 назад занялся он продажей стройматериалов. Кирпич-цемент и т.п. Да цифрой в объявлении ошибся (или "редакторы" ошиблись, не суть). Именно тогда, впервые, я узнал что где-то в Ульяновске живет предприимчивый человек с номером телефона, отличающимся от моего всего на одну цифру. В следующих номерах газеты, был уже правильный номер. Оттуда, я его собственно и узнал.

С тех пор начало строительного сезона я знаменуется для меня звонками с вопросами о "моих товарах". Я честно отвечаю, что я этого не продаю, но могу подсказать номер где им помогут :D Не подумайте плохого, не часто в объявлениях мой номер указывают. Звонящие сами ошибаются.

Чего это я его вспомнил осенью? Поделиться радостью. Недавно мне позвонили спрашивали, можно ли у меня окна пластиковые заказать :) Не успел я на пусть истинный наставить. Однако, в этот раз звонящая дама произнесла именно мой номер...

Блин, жаль денег нет, чтобы конкурс объявить. Типа, кто найдет газету с моим номером и позвонит по нему? Тому новенький iчё-нибудь и рукопожатие.

Так о чем это я? Ах,да. Растет чувак! Глядишь, через пару лет будут спрашивать г-на Somebody. Вот такой пассивный мониторинг у меня идет...

А что бы вы делали на моем месте?