Форум

[QUOTE]Александр Панишев написал:
мне аналогично прикатилось сразу по нескольким серверам

только вот у меня не этот вариант

Екатерина Шемаева написал:
возможна в случае, если используется тип виртуализации, где не поддерживается iptables (например, openvz + venet интерфейс)

у меня просто серваки на которых типовое веб окружение развернуто без чего либо дополнительного[/QUOTE]
В любом случае без просмотра:
- лога заданий на серверe
- текущей настройки iptables
Сложно что-либо сказать.
[QUOTE]Николай Ермаков написал:
Я написал обращение в ТП Битрикс для чистоты исследования.[/QUOTE]
Спасибо!

[QUOTE]Николай Ермаков написал:
Жалоба из ДТ на наш сервер!
....
Плюс невозможность подключится к сервису.
[/QUOTE]
Было бы интересно посмотреть на конфигурацию Вашего iptables ( iptables --list).  Можно через запрос в ТП
По умолчанию мы предполагаем, что может быть сделана кластерная конфигурация или/и memcached будет находится на отдельном сервере с настроенным мониторингом, соотвественно memcached  слушает все доступные интерфейсы.
НО, для безопасности мы не открываем порт 11211 для доступа через iptables.

Например,
кластер из двух машин  [CODE]srv01 172.17.0.11
srv02 172.17.0.12[/CODE]Будет содержать в iptables следующие правила:[CODE]Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
   pkts      bytes target     prot opt in     out     source               destination
    313    27652 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
      1      116 ACCEPT     tcp  --  *      *       172.17.0.12          0.0.0.0/0           tcp /* Access to host from srv02.ksh.bx */
      0        0 ACCEPT     udp  --  *      *       172.17.0.12          0.0.0.0/0           udp /* Access to host from srv02.ksh.bx */
      0        0 ACCEPT     tcp  --  *      *       172.17.0.11          0.0.0.0/0           tcp /* Access to host from srv01.ksh.bx */
      0        0 ACCEPT     udp  --  *      *       172.17.0.11          0.0.0.0/0           udp /* Access to host from srv01.ksh.bx */[/CODE]То есть, разрешения на доступ к 11211 не дан, но так как есть указанные правила для адресов серверов, доступ возможен с любого сервера внутри кластера и не возможен с других. Аналогичная логика используется для mysql, sphinx, web ролей.

Соответвенно, та ситуация,  о которой пишет Ваш ДЦ, возможна в случае, если используется тип виртуализации, где не поддерживается iptables (например, openvz + venet интерфейс)
Проверить можно добавив любое правило в таблицу:[CODE]iptables -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT[/CODE]Если вернет ошибку, значит iptables не были настроены из меню, в том числе.

В таком случае, Вы можете сказать mecached слушать только localhost:
1) открываем файл /etc/sysconfig/memcached на редактирование и меняем[CODE]OPTIONS=""[/CODE]на[CODE]OPTIONS="-l 127.0.0.1"[/CODE]2) перезапускаем memcached
Внесла себе этот кейс, в следующей версии появится возможность выбора  IP адреса.

[QUOTE]Руслан Манаенко написал:
сделали так:  
/root/.my.cnf  
создали файлик: /root/.my.cnf  
В нем добавили следующие строки:

[client]
socket=/var/lib/mysqld/mysqld.sock
user=root
password=XXXXXXXXXXXXXXXXXX

В итоге все равно получаем: msg: unable to connect, check login_user and login_password are correct, or alternatively check ~/.my.cnf contains credentials - как побороть?? [/QUOTE]
А подключится из консоли стандартным клиентом, возможно?

Например, можно проверить корректность настроек следующим образом:
Хороший ответ
[CODE]mysqladmin ping
mysqld is alive[/CODE]Плохой ответ:[CODE]mysqladmin ping
mysqladmin: connect to server at 'localhost' failed
error: 'Access denied for user 'test'@'localhost' (using password: YES)'[/CODE]

[QUOTE]Alexander Bar написал:
1) Не видит предыдущие настройки nginx & apache
Даже конфиги пропали.
2) Из /root/menu.sh тоже не видит старые настройки.
           6. Manage sites in the pool
           Говорит что нет у меня сайтов


Что я сделал не так? [/QUOTE]
C какой до какой версии обновлялись?
Пункт 2 очень похож на обновление с версии 4.3 до версии 5.х (они не совместимы, соотвественно, меню не будет видеть старые конфигурации, в таких случаях мы рекомендуем сделать бэкап и восстановить конфигурацию через новое меню)
Если не сложно, напишите в ТП^ приложите следующую информацию:
1) понадобятся логи из каталога /opt/webdir/temp
2) лог обновления: /opt/webdir/logs/install_5.1-0.el6.log
3) вывод команды: [CODE]/opt/webdir/bin/bx-sites -a list[/CODE]

[QUOTE]Руслан Манаенко написал:
И на этом все.. обновление не свершилось - сканер безопасности все равно ругается на устаревшую версию..
А кто-то вообще обновился положительно?[/QUOTE]

Задание обновления php/mysql фоновое.
Сделано специально, так как в случае отключения от  ssh сессии оно продолжит выполнение, а не прервется на самом интересном месте.

Задание ведет лог выполнения, который привязан к JobID, в Вашем случае:
/opt/webdir/temp/[B]upgrade_mysql_php_2102032614[/B]/status
Там есть информация по каждой операции, а так же финальный результат.

То есть интересно,
1) есть ли ошибки в финальном результате значения для  failed или unreach большие нуля, при успешном выполнение, должно быть что-то в духе:[CODE]PLAY RECAP ********************************************************************
test               : ok=43   changed=32   unreachable=0    failed=0[/CODE]2) Если есть ошибки, то ищем в status файле, текст ошибки - поиск по failed/error
Наверное, в любом случае если была ошибка, или задание выполнилось без них, но обновление не выполнено, удобнее будет дальше общаться через тикет в ТП, так понадобится дополнительная информация, как минимум файлик status из задания.


Задание обновления, полностью сделано через сценарий/playbook системы управления конфигурациями ansible [URL=http://docs.ansible.com/index.html]ansible[/URL]
Поэтому если хотите получить больше контроля над процедурой обновления, то
1) перейти в виртуальный терминал (tmux, screen) - необходимо, учитывая время выполнения операции и возможность прерывания ssh сессии
2) запустить обновление через сценарий:[CODE]ansible-playbook /etc/ansible/upgrade_mysql_php.yml[/CODE]

[QUOTE]Михаил Лабенский написал:
Пробежал форум - не нашел ответа - пытаюсь удалить хост из пула - тут конечно все красиво нарисованно: [URL=http://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=37&LESSON_ID=6520&LESSON_PATH=3908.6488...]http://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=37&LESSON_ID=6520&LESSON_PATH=3908.6488....[/URL].

Но у меня пишет "You must delete all roles from server2"
Вопрос к знатокам - как его удалять то ?[/QUOTE]
[B]Тут существует два варианта:[/B]
1)  машина доступна, на ней есть роли ( memcached, mysql или что-то другое)
Тогда нужно, удалить роли, затем удалить машину из пула
2) машины не доступна, давно выключена и не используется
Тут, решения из меню пока нет (есть в планах, постараемся сделать к следующему релизу)
Но можно удалить запись о машине вручную:[CODE]/etc/ansible/hosts[/CODE]И запустить обновление конфигурации[CODE]ansible-playbook /etc/ansible/common.yml[/CODE]Если сомневаетесь, то ТП сможет подсказать подробности по всем вариантам.

[QUOTE]Антон Кисляков написал:
msg: unable to connect, check login_user and login_password are correct, or alternatively check ~/.my.cnf contains credentials

рутовый пароль для mysql нами был сменен еще в первых версиях bitrix_env

не понятно где он требует найти реквизиты[/QUOTE]
Он пробует найти реквизиты в файле: ~/.my.cnf, это стандартное поведение для mysql клиентов.

Символ ~  соответствует домашнему каталогу текущего пользователя ( в случае запуска из меню, это будет /root), полный путь к файлу /root/.my.cnf
Нужно сделать файлик: /root/.my.cnf
В нем добавить следующие строки:[CODE][client]
socket=/var/lib/mysqld/mysqld.sock
user=root
password=XXXXXXXXXXXXXXXXXX

[/CODE]
И запустить обновление из меню.
Учтите, что время обновления  базы, зависит от ее размера так, как:
- перед взлетом делается бэкап БД сайта
- после обновление пакеты запускается mysql_upgrade
Соответственно, лучше запланировать обновление на время с минимальной посещаемостью, именно, поэтому мы не стали делать обновление из rpm пакета.

Новые версии образов машин, а так же установка из bitrix-env.sh идет с новыми версия php 5.4 и mysql 5.5, если сомневаетесь, возможно, стоит сделать бэкап и перенести проект в новый образ.

[QUOTE]Александр Панишев пишет:
рискнул на своих проектах, работоспособность того что было раньше сохраняется, но глюк с добавлением сайтов стабильно сохраняется начиная с момента выхода пятерки.

Первый раз проверил создав сайт сразу после выхода пятерки, проблему решила ТП, надеялся что в 5,0,44 исправили но ничего подобного все так же...

Не вводите народ в заблуждение...
[/QUOTE]
Проблема возникла из-за обновления ПО,которое мы используем внутри(ansible).  В тот момент, когда мы выпустили обновление 5.0.37, обновилась версия ansible, где поменялась работа булевых переменных, которые как раз использовались в этих конфигах.

Самый простой вариант, поправить значение переменной в конфигурационном файле
/etc/ansible/group_vars/bitrix-web
в случае если web кластер не создавался ( роль apache одна)
[CODE]cluster_web_configure: disable[/CODE]в случае если web-кластер есть,
[CODE]cluster_web_configure: enable[/CODE]
После этого, создание сайта в новой версии должно проходить без проблем.