если база большая то с данными наверное будет проблемка
а схему то какие проблемы сравнить mysqldump -u root -p --no-data dbname diff -u file1 file2 > file3
данные можно быстро проверить просто пройдясь по количеству строк в каждой таблице
может чтото будет очевидно сразу
я правильно понимаю что у вас отдлеьная репа где в мастере лежит куча jenkinsfile
и вы когда добавляете новый - создаете новую джобу для определенного пути к новому jenkinsfile?
не проще тогда сканировать все ветки и под каждый jenkinsfile создавать отдельную ветку?
тогда можно одной multipipeline джобой обойтись поидее
первый вопрос мой конечно не совсем корректен
конечно дописать код можно в php файлы
я имел в виду что по-моему вряд ли это входит в стандартный пакет поломки подобных приложений
Виталий Р,
как вирус может сидеть в пхп файлах? (кроме варианта когда программист специально туда уязвимость намеренно добавил)
никто ваши пхп-файлы патчить не будет потому что нахрен вы кому сдались со своими 4ю микросайтами
вас же явно ломают автоматически а не вручную. вы представляете себе какой это геморрой делать reverse-engineering ваших приложений, а потом писать что-то кастомно заточенное для конкретного сервера. эти временные затраты вы не окупите никогда. Это ведь тоже софт, его писать нужно, тестировать нужно, обкатывать.
Грубо говоря есть миллион серверов. на них миллион разных сайтов.
но все они ранаются на апаче. Поэтмоу использовать будут уязвимость апача а не вашего пхп приложения - потому что этим решением можно поломать миллион хостов а не ваш 1. Тогда это имеет экономическую целесообразность.
поэтому ломают "ковровым бомбометанием" сканируют сеть и проверяют на наличие известных уязвимостей у известного ПО всю сеть сразу. КТо просканился успешно - тому вставляют стандартный майнер.
Я могу быть не прав что ваше приложение (php) никак в процессе не участвует
на уровне логики приложения могут какие-то косяки в безопасности типа позволено аплоадить какие-то стремные файлы на сервер без проверки mime-type или чо-нить типа того.
Но опять же даже если это так - то это результат испольования стандартного известного типа уязвимостей а не результат пристального и скурпулезного поиска уязвимости в вашем сайте
если сайты деплоились гитом можете пойти в папку с сорцами и посмотреть git status
я уверен на 99% что там будет все чисто
ну учитывая что никто в результате кроме вас не заинтересован - то удачи Ж)
шучу
на самом деле если время позволяет и сайты простенькие - мигрировать их на другую машину где все ПО обновлено в принципе не сильно сложно
грубо говоря если там 4 сайта-визитки лежит - то перенести их на новую машину дело плевое
может стоит в эту сторону посмотреть
хотя сказать честно - для меня Ваша ситуация удивительна
у нас любых людей которые хотя бы книгу по питону прочитали - отрывали с руками
а у вас чот балованые все
ну то такое
все равно что-нибудь найдется в итоге
все через это проходили
не отчаивайтесь
ну если уж так формально смотреть то мы ничего не нарушаем
база за фильтрацию, сортировки и не должна отвечать
ее задача (грубо говоря) дать вам хранимое состояние системы которое гарантированно устойчиво к ребутам рестартам и прочей ерунде (кароче то что называется persistence )
все остальное - ну бонусы опциональные
судя по иконке это тоже самое что "недавние" ;)