Admin's tips & tricks

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

Есть такая замечательная штука spread. Она позволяет создать сервер сообщений, сообщения туда можно посылать и принимать. Для чего это нужно? Скажем есть у нас 100 демонов, которые читают данные из базы, база изменилась - надо ее перечитать. Демоны слушают сообщения, достаточно послать одно и все перечитают.

После пятничных движений на серверах spread-фичи перестали работать. Как показали логи - отвалился php-spread модуль, который реализует функционал отправки сообщений spread'у.

На вопрос как поставить спред гугл предлагает примерно такой путь:

apt-get php-dev phpize pecl

pecl install spread

PROFIT!!!

Но не прокатило. Spread вываливается с ошибкой компиляции.

Решение:

Идем на http://pecl.php.net/package/spread и берем последнюю (от аж 2008 года версию спреда), разжимаем архив, применяем вот этот:

--- php_spread.c.orig   2011-05-24 08:26:40.000000000 +0000

+++ php_spread.c        2011-05-24 08:28:30.000000000 +0000

@@ -17,7 +17,7 @@

   |         Rob Richards <[email protected]>                            |

   +----------------------------------------------------------------------+

 */

-/* $Id: php_spread.c,v 1.54 2008/10/22 16:23:29 rrichards Exp $ */

+/* $Id$ */

 #include "config.h"

@@ -45,7 +45,6 @@

 static int le_conn;

 /* {{{ arginfo */

-static

 ZEND_BEGIN_ARG_INFO_EX(arginfo_spread_connect, 0, 0, 1)

        ZEND_ARG_INFO(0, spread_daemon)

        ZEND_ARG_INFO(0, private_name)

@@ -105,7 +104,7 @@

 /* {{{ spread_functions[] */

-function_entry spread_functions[] = {

+zend_function_entry spread_functions[] = {

        PHP_FE(spread_connect, arginfo_spread_connect)

        PHP_FE(spread_multicast, arginfo_spread_multicast)

        PHP_FE(spread_disconnect, arginfo_spread_disconnect)

@@ -358,7 +357,7 @@

        {

                php_info_print_table_row(2, "Spread", "enabled");

                php_info_print_table_row(2, "Version", PHP_SPREAD_VERSION);

-               php_info_print_table_row(2, "CVS Id", "$Id: php_spread.c,v 1.54 2008/10/22 16:23:29 rrichards Exp $");

+               php_info_print_table_row(2, "CVS Id", "$Id$");

                if (SP_version( &mver, &miver, &pver)) {

                        snprintf(sp_version, 128, "%d.%d.%d", mver, miver, pver);

                        php_info_print_table_row(2, "Spread version", sp_version);

@@ -423,7 +422,7 @@

        mailbox *mbox = NULL;

        char private_group[MAX_GROUP_NAME];

        int rsrc_id;

-       list_entry *le;

+       zend_rsrc_list_entry *le;

 #ifdef ZEND_ENGINE_2

        zval *this = getThis();

@@ -867,7 +866,9 @@

                if (Is_reg_memb_mess(stype)) {

                        /* join/leave/disconnect/network */

+#if (SPREAD_VERSION >> 24) >= 4

                        membership_info memb_info;

+#endif

                        char *changed_member;

                        add_assoc_long(return_value, "group_size", ngrps);

После перехода с самосборного пакет php 5.2 на php 5.3 из убунтовских реп в лог стало валиться примерно следующее:

PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php5/20090626/mhash.so' - /usr/lib/php5/20090626/mhash.so: cannot open shared object file: No such file or directory in Unknown on line 0

Поиск в гугле посоветовал удалить файлик mhash.ini, но его у меня нет. Проблема оказалось в следующем: php брал настройки из php.ini, который контролится puppet'ом и почти без изменений переехал из 5.2 в 5.3, а в нем уже была строчка, загружающая mhash.so

Строчку я закомментил и все стало круто.

Примерно год назад я из-за взаимонепонимания с работодателем на собеседовании попал в одну очень крупную компанию на очень мелкую должность, а именно работал эникеем.  Сказали сисадмин, оказалось чинитель компов и записыватель дисков. Однако в распоряжении у меня было аж 3 сервера, один из которых был под убунтой. На момент принятия меня на работу у них уже был эникей и его попросили передать мне дела. Дел было немного, но чел считал себя очень крутым админом и рассказывал мне о "такой операционной системе, как линукс". :) Через пару дней работы понадобился мне доступ в одну диру на том самом серваке под убунтой. Просто зайти и посмотреть содержимое одного файлика. Рута у меня тогда еще небыло, ибо их эникей никак его (рута) мне отдавать не хотел, поэтому я попросил его дать права на "посмотреть файлики".

Ситуация сложилась забавная. Он говорит, что права дал, cd в диру я сделать не мог. Мучался мой предшественник наверно пол часа - час, после чего я таки посмотрел сам и посоветовал сделать chmod +x, т.к. он до этого упорно давал r или rw.

Мораль сей басни такова: для того, чтобы зайти в диру нужно +x для того, чтобы сделать ls в дире надо +r

Еще когда я только начинал свое знакомство с линуксами (это был кажется RedHat 6.2), столкнулся с сабжем. Создал файлик в /tmp от одного юзера, назначил ему 777, потом попробовал удалить от другого юзера и не смог, что повергло в ступор. В других дириах все работало, а в tmp - нет. ls -la показал примерно следующее:

drwxrwxrwt   4 root root  4096 2011-09-03 04:00 tmp

у других дир было rwx вместо rwt. Тогда я понял, что в дире с правами rwt удалить файл может только владелец, но для меня осталось загадкой что это такое и с чем это едят. Чуть позже у меня оказался интернет и я узнал, что это sticky bit, который придумали еще в 1974 году для уменьшения времени загрузки наиболее часто используемых программ. После закрытия программы код и данные оставались в памяти, а следующий запуск происходил быстрее. Сейчас его используют в основном на директориях. Из такой директории пользователь может удалить только те файлы, владельцем которых он является.

Сегодня после apt-get update на одном из серваков отвалилась репликация MySQL. Починилось примерно так:

Заходим на реплику, говорим SHOW SLAVE STATUS \G;

Получаем ответ вида Relay log read failure: Could not parse relay log event entry. И дальше советы проверить на корректность бинлог мастера и релей лог слейва

Пробуем mysqlbinlog на указаные в п.2 логи, нифига толкового не видим.

STOP SLAVE

SHOW SLAVE STATUS

Запоминаем значения 'Relay_Master_Log_File' и 'Exec_Master_Log_Pos'

RESET SLAVE

CHANGE MASTER TO ..... (подставляем MASTER_LOG_FILE=relay_master_log_file и MASTER_LOG_POS=exec_master_log_pos из шага 6)

START SLAVE

PROFIT!!!

Еще один пост про редмайн.

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

Задача сразу поставлена с этой датой, что подразумевает сделать к такому то числу

Человек получил задачу и сразу поставил дату, что подразумевает, что к этому числу она будет выполнена

Человек ставит дату при выполнении задачи.

Теперь еще немного отвлечемся и вспомним, что задачи можно закрывать коммитом в репу, привязанную к проекту вида fixes #<issue number> Таким образом задачу мы закрыли, а вот поставить дату придется руками + многие (и я в том числе) забывают при выполнении задачи ставить дату выполнения, что не есть хорошо.

Задача: ставить текущую дату как дату выполнения автоматом, при переводе задачи в статус "выполнена". Если дата уже стоит - ничего не менять.

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

create function close_issue_trigger() returns trigger AS ' begin if (NEW.status_id=15) then     if (NEW.due_date is NULL) then       NEW.due_date=current_date;     end if;   end if;

  return NEW; end; ' language plpgsql;

create trigger close_issue_date before update on issues for each row execute procedure close_issue_trigger();

Что это делает?

Наверное многие из тех, кто занимается разработкой софта используют в своем нелегком труде такую штуку, как redmine. Там, где я сейчас работаю ее тоже используют, а еще используют такой функционал редмайна, как подзадачи.

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

Взглянув на HTML код редмайна можно увидеть примерно следующее:

<p><strong>Подзадачи</strong></p> <form><table class="list issues">

Теперь идем на сервер где лежит редмайн и делаем grep -iRn list-issues по директории с редмайном и получаем:

./app/helpers/issues_helper.rb:69:    s = '<form><table class="list issues">' ./app/views/issues/_list.rhtml:4:<table class="list issues"> ./app/views/issues/_list_simple.rhtml:3:        <table class="list issues">

Нас интересует первый файл. Изначально в нем:

             content_tag('td', h(child.status)) +              content_tag('td', link_to_user(child.assigned_to)) +

Добавляем строчку, чтобы получилось так:

             content_tag('td', h(child.status)) +              content_tag('td', h(child.priority.name)) +              content_tag('td', link_to_user(child.assigned_to)) +