red_eye, спасибо за ссылку, буду изучать этот вариант! Но пока без докера нужно по быстрому развернуть проект, бекап я уже восстановил (решил вот эту проблему с доступом к БД при восстановлении из бекапа https://dev.1c-bitrix.ru/community/forums/forum23/topic141430/) сайт развернулся, работает, но ЧПУ не работает, где бы посмотреть эти конфиги для NGINX? Они нужны для стандартного функционала, сайт без каких либо доработок по роутингу все стандартное.
Здравствуйте, как то все время использовал BitrixEnv но сейчас встала необходимость развертывания Bitrix на LEMP. Кто может подсказать какие там есть нюансы и подводные камни? Как решать проблему отсутствия Apache и т.д?
BitrixVM 7.5.x - обновление GIT затирает bitrix-env, GitLab CI/CD падает в ошибку из за версии git 1.8.1 - fatal: git fetch-pack: expected shallow list
BitrixVM 7.5.x - обновление GIT затирает bitrix-env, GitLab CI/CD падает в ошибку из за версии git 1.8.1 - fatal: git fetch-pack: expected shallow list
написал: И очень зря, при взломе гит очень помогает.
не понятно просто как мне не затирать изменения которые клиент будет через эрмитаж вносить в конфигурациях компонентов или создании новых разделов, подразделов и страниц сайта... по этому и отказался от git... т.е от такого
И кстати не понятно зачем мне добавлять в секцию script команды гита если как я и описал выше, на сервере не используется git для файлов сайта... Вот это момент я вообще не понял, вы предлагает от rsync отказаться или одновременно с ним использовать эти команды (какие кстати?)?
BitrixVM 7.5.x - обновление GIT затирает bitrix-env, GitLab CI/CD падает в ошибку из за версии git 1.8.1 - fatal: git fetch-pack: expected shallow list
red_eye, в какой скрипт? дело в том что на сервере я не использую гит, для того что бы подтягивать изменения из репозитария. Изменения прилетают на сервер по rsync. Это сделано для того что бы мне не пришлось учитывать что админы сайта могут менять файлы через "эрмитаж" например.
BitrixVM 7.5.x - обновление GIT затирает bitrix-env, GitLab CI/CD падает в ошибку из за версии git 1.8.1 - fatal: git fetch-pack: expected shallow list
написал: Нужные команды, типа git pull / git clone и прочие можно добавить в сам скрипт. Они вполне нормально работают с git из centos 7
не проверил сразу.. джобы то теперь завершаются без ошибок, но файлы измененные почему то не прилетают на сервер.. т.е изменений нет на сервере после отработки джобы с этой переменной GIT_STRATEGY: none почему так, как пофиксить?
BitrixVM 7.5.x - обновление GIT затирает bitrix-env, GitLab CI/CD падает в ошибку из за версии git 1.8.1 - fatal: git fetch-pack: expected shallow list
BitrixVM 7.5.x - обновление GIT затирает bitrix-env, GitLab CI/CD падает в ошибку из за версии git 1.8.1 - fatal: git fetch-pack: expected shallow list
Приветствую! Возникла потребность настроить CI/CD на GitLab с помощью runner После того как раннер зарегистрирован и активен, и настроено соединение с сервером по ssh ключам, деплои проходят норм, но спустя время (пару дней), Jobs`ы начинают сваливаться в ошибку
Код
fatal: git fetch-pack: expected shallow list
fatal: The remote end hung up unexpectedly
и если последовать примеру ее решения на BitrixVM 7.5.x, которое заключается в удалении и установки GIT
Код
sudo yum remove git
то вместе с git зависимостями будут удалены пакеты
bitrix-env etckeeper perl-Git
в следствии чего мы теряем виртуальную машину.... которую затем восстановить предложенным способом, лично у меня не получилось (она установилась, но критический функционал в ней по добавлению сайтов к примеру не заработал)
Может кто то сталкивался с такой проблемой, как ее можно решить что бы деплой заработал, т.е как безопасно обновить git на BitrixVM 7.5.x ?
Деплой организован с помощью rsync т.е по сути то git на сервере с VM в принципе не нужен и никак не используется... но почему то GitLab матюкается что версия старая...
red_eye, не заработало, убрал все что добавил ранее из всех файлов, и добавил последний вариант в /etc/nginx/bx/conf/bitrix.conf файл лога не появляется, т.е правило не выполняется...
Взломали Bitrix24 (сносят полностью /home/bitrix) при повторном взломе еще и файлы OS повреждают (ТП хостинга FVDS переустанавливала)
Логи OS и сервера NGINX по ним видно что прогоняли через сервис поиска уязвимостей https://leakix.net/ искали конфиг SFTP клиента VSCode которые по ошибки могли улететь на сервер https://clck.ru/35ccmB (и не только это)
От: - 2023-09-07 10:46:39 По неизвестным причинам пропала часть файлов, которые нужны для корректной загрузки и работы ОС. Пытаемся восстановить их. Точных сроков пока назвать, к сожалению, не можем.
-- С уважением, Системный администратор службы технической поддержки FirstVDS
Цитата
От: - 2023-09-07 11:37:51 На сервере отсутствовали файлы, необходимы для загрузки ОС. Переустановили ядро и загрузчик - сервер запустился. В данный момент видим, что отсутствует директория /home/bitrix, т.е. все файлы сайта. При этом другие директории, судя по всему, не затронуты: MySQL запущен и работает, базы данных на месте. Также на месте файлы в директории /ts (судя по всему это какие-то старые бекапы).
Вижу по переписке, что ранее ваша система была взломана, вероятно это послужило причиной.
Рекомендуем заказать новый сервер, и восстановить сайты на нем из резервных копий. Для этого вы можете обратиться к нам.
-- С уважением, Системный администратор службы технической поддержки FirstVDS
Добавьте в NGINX блокировку POST запросов к файлам
Столкнулся с проблемой, после 2х выключений электричества, на локальной VMBitrix перестала работать mysql
проверка статуса сервиса дает такой ответ
Код
[root@bitrix_vm3 ~]# systemctl status mysql
? mysqld.service - MySQL Server
Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled; vendor preset: disabled)
Active: failed (Result: start-limit) since Tue 2023-07-25 22:53:02 MSK; 1h 49 min ago
Docs: man:mysqld(8)
http://dev.mysql.com/doc/refman/en/using-systemd.html
Process: 2479 ExecStart=/usr/sbin/mysqld --daemonize --pid-file=/var/run/mysqld/mysqld.pid $MYSQLD_OPTS (code=exited, status=1/FAILURE)
Process: 2455 ExecStartPre=/usr/bin/mysqld_pre_systemd (code=exited, status=0/SUCCESS)
Jul 25 22:53:02 bitrix_vm3 systemd[1]: Failed to start MySQL Server.
Jul 25 22:53:02 bitrix_vm3 systemd[1]: Unit mysqld.service entered failed state.
Jul 25 22:53:02 bitrix_vm3 systemd[1]: mysqld.service failed.
Jul 25 22:53:02 bitrix_vm3 systemd[1]: mysqld.service holdoff time over, sc...t.
Jul 25 22:53:02 bitrix_vm3 systemd[1]: Stopped MySQL Server.
Jul 25 22:53:02 bitrix_vm3 systemd[1]: start request repeated too quickly f...ce
Jul 25 22:53:02 bitrix_vm3 systemd[1]: Failed to start MySQL Server.
Jul 25 22:53:02 bitrix_vm3 systemd[1]: Unit mysqld.service entered failed state.
Jul 25 22:53:02 bitrix_vm3 systemd[1]: mysqld.service failed.
Hint: Some lines were ellipsized, use -l to show in full.
Попытки перезапустить, активировать\деактивировать, убить процесcы mysql, удаление файлов /var/run/mysqld/mysqld.pid и /var/lib/mysqld/mysqld.sock ни к чему не приводят, сервис не стартует...
Код
[root@bitrix_vm3 conf.d]# sudo systemctl start mysqld.service
Job for mysqld.service failed because the control process exited with error code. See "systemctl status mysqld.service" and "journalctl -xe" for details.
[root@bitrix_vm3 conf.d]# sudo systemctl status mysqld.service
● mysqld.service - MySQL Server
Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled; vendor preset: disabled)
Active: activating (start) since Wed 2023-07-26 02:03:50 MSK; 3s ago
Docs: man:mysqld(8)
http://dev.mysql.com/doc/refman/en/using-systemd.html
Process: 18663 ExecStartPre=/usr/bin/mysqld_pre_systemd (code=exited, status=0/SUCCESS)
Control: 18687 (mysqld)
CGroup: /system.slice/mysqld.service
├─18687 /usr/sbin/mysqld --daemonize --pid-file=/var/run/mysqld/mysqld.pid
└─18690 /usr/sbin/mysqld --daemonize --pid-file=/var/run/mysqld/mysqld.pid
Jul 26 02:03:50 bitrix_vm3 systemd[1]: Starting MySQL Server...
часть лог файла полученный по пути /var/log/mysql/error.log
Код
2023-07-25T22:29:38.932179Z 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html for information about forcing recovery.
2023-07-25T22:29:38.995898Z 0 [Note] InnoDB: 2 transaction(s) which must be rolled back or cleaned up in total 0 row operations to undo
2023-07-25T22:29:38.995921Z 0 [Note] InnoDB: Trx id counter is 3174656
2023-07-25T22:29:39.003107Z 0 [Note] InnoDB: Cleaning up trx with id 3132548
2023-07-25T22:29:39.003128Z 0 [Note] InnoDB: Cleaning up trx with id 3132398
2023-07-25T22:29:39.323692Z 0 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"
2023-07-25T22:29:39.323716Z 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2023-07-25T22:29:39.323754Z 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2023-07-25T22:29:39.355900Z 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
2023-07-25T22:29:39.356631Z 0 [Note] InnoDB: 96 redo rollback segment(s) found. 96 redo rollback segment(s) are active.
2023-07-25T22:29:39.356641Z 0 [Note] InnoDB: 32 non-redo rollback segment(s) are active.
2023-07-25T22:29:39.357943Z 0 [Note] InnoDB: Waiting for purge to start
2023-07-26 01:29:39 0x7f0fb95f5700 InnoDB: Assertion failure in thread 139705511270144 in file fut0lst.ic line 93
InnoDB: Failing assertion: addr.page == FIL_NULL || addr.boffset >= FIL_PAGE_DATA
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
22:29:39 UTC - mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
Attempting to collect some information that could help diagnose the problem.
As this is a crash and something is definitely wrong, the information
collection process might fail.
Please help us make Percona Server better by reporting any
bugs at https://bugs.percona.com/
key_buffer_size=50331648
read_buffer_size=131072
max_used_connections=0
max_threads=44
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 407537 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Build ID: f63b7082d764297ccdfd239bd51989633fcefefb
Server Version: 5.7.37-40 Percona Server (GPL), Release 40, Revision 3a1347ec0d4
Thread pointer: 0x7f0fa80008c0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 7f0fb95f4cb0 thread_stack 0x20000
/usr/sbin/mysqld(my_print_stacktrace+0x3b)[0xf4624b]
/usr/sbin/mysqld(handle_fatal_signal+0x505)[0xd779c5]
/lib64/libpthread.so.0(+0xf630)[0x7f1027ebe630]
/lib64/libc.so.6(gsignal+0x37)[0x7f1025fbb387]
/lib64/libc.so.6(abort+0x148)[0x7f1025fbca78]
/usr/sbin/mysqld[0x7824cc]
/usr/sbin/mysqld[0x782008]
/usr/sbin/mysqld[0x1160265]
/usr/sbin/mysqld[0x1162b65]
/usr/sbin/mysqld(_Z9trx_purgemmb+0x26b)[0x11659db]
/usr/sbin/mysqld(srv_purge_coordinator_thread+0xa47)[0x1137647]
/lib64/libpthread.so.0(+0x7ea5)[0x7f1027eb6ea5]
/lib64/libc.so.6(clone+0x6d)[0x7f1026083b0d]
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0): Connection ID (thread ID): 0
Status: NOT_KILLED
You may download the Percona Server operations manual by visiting
http://www.percona.com/software/percona-server/. You may find information
in the manual which will help you identify the cause of the crash.
Есть ли шанс восстановить БД или нет? Если нет то как можно ее переустановить не прибегая к сносу самой VM ?
Где вообще реализация возможности для клиента по отписке от рассылки, которая по требованию из закона о рекламе должна быть в письме (стоять ссылкой на стр. с формой отписки)
Цитата
Здравствуйте, C вашей услуги VDS-KVM-NVMe-Битрикс-Турбо #13018827 (37.46.173.88, site.ru) зафиксирована массовая рассылка почтовых сообщений. Мы подозреваем, что сервер рассылает спам, а это запрещено правилами предоставления наших услуг (https://firstvds.ru/docs/main/usloviya_predostavleniya_uslug_ao_iot.pdf Согласно пунктам 3.7-3.8-3.9-3.10-3.11). Сейчас исходящий почтовый трафик сервера автоматически заблокирован.
ЭТО ЛЕГАЛЬНАЯ РАССЫЛКА? Если это легальная рассылка, то мы разблокируем 25, 465, 587 порты и добавим IP адрес вашего сервера в “белый” список.
Для попадания IP в белый список необходимо выполнить следующие условия: 1. Подскажите, каким образом подписчики дают согласие на получение рассылки? (Согласно закону о рекламе, у вас должна быть информация о том, в какое время и с какого IP-адреса каждый пользователь дал подтверждение на рассылку. Иначе рассылка классифицируется как СПАМ) 2. Предоставьте пример отправляемого письма. У получателя должна быть возможность быстро отписаться от рассылки. (можно прислать скриншот или исходник письма) 3. Если в вашем случае рассылаются иные уведомления с учебных сайтов, магазинов или любые технические уведомления, то укажите сайт и приложите скриншот или исходник письма В БЕЛЫЙ СПИСОК НЕ ВНОСЯТСЯ СЕРВЕРЫ, ЕСЛИ: 1. Рассылаются технические уведомления cron 2. Рассылки носят рекламный характер 3. Осуществляется распространение любым способом содержащей рекламу информации без прямого согласия со стороны конечного получателя. Например: письма, содержащие ссылку на некий ресурс сети и подразумевающие, что получатель должен его посетить, спам (в том числе - поисковый); 4. Организуется и/или осуществляется несогласованная отправка одного письма множеству получателей, несогласованная множественная отправка писем одному получателю, иная несогласованная отправка писем; 5. Осуществляется реклама товаров и/или услуг, распространение которых ограничено и/или запрещено Законодательством РФ; 6. Организуется и/или осуществляется принудительная подписка почтового адреса на любые периодические рассылки без предварительного подтверждения владельца адреса, периодическая рассылка, не содержащая явного указания на способ от них отписаться, отправка информации лицам, ранее не выразившим явного желания получать указанную информацию; 7. Организация и/или распространение любым способом списков адресов электронной почты третьих лиц, схем «пирамид», многоуровневого (сетевого) маркетинга (MLM), систем Интернет-заработка и e-mail-бизнесов, в том числе в случаях, если отправка производилась без непосредственного использования Услуг;
В случае обнаружения несоответствия полученных ответов действительности или при получении жалоб от Spamcop, Spamhaus и подобных сервисов разрешение на рассылку аннулируется.
ВЫ НЕ ДЕЛАЕТЕ НИКАКИХ РАССЫЛОК? Если не вы инициировали эту рассылку, то ваш сервер взломан.
Как оказалось не работало из-за сертификата версии TLSv1.3, заменил строку /etc/nginx/bx/conf/ssl-push.conf:11 с ssl_protocols TLSv1.2 TLSv1.3; на ssl_protocols TLSv1.2;