Dimka Filippov

#!/bin/bash
IFS='
'
exec 3<>data.txt
while read -u 3 line
do
(
        IFS=' '
        result=()
        for word in $line
        do
                [[ ! "${result[*]}" =~ "$word" ]] && result=(${result[*]} $word)
        done
        echo ${result[*]}
)
done

sudo cat /var/log/mysql/error.err | egrep '[aA]ccess denied'

https://serverfault.com/a/455610

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

1. вместо действительного MySQL запустить программу-приманку.
   https://github.com/sjinks/mysql-honeypotd
   
2. далее, можно установить atop, acct:
   sudo apt install acct atop
   atop собирает информацию о производительности системы и запускаемых процессах
   acct ведет мониторинг активности пользователей (в частности, sa выводит список процессов)
   
   https://haydenjames.io/use-atop-linux-server-perfo...
   https://www.tecmint.com/how-to-monitor-user-activi...
   
   соберет статистику за полдня-день и тогда можно анализировать историю так:
   atop -r /var/log/atop/atop_20200729
   
3. Если не хватит, то у меня появилась такая идея: можно написать программу. Она может слушать на порту 3306 и регистрировать IP адрес и также узнавать номер процесса клиента, по которому можно узнать и путь и от какого пользователя запущен.
   Узнать номер процесса по прослушиваемому порту
   sudo lsof -i :2345
   Узнать что за пользователь и откуда запускается
   

   ls -l /proc/6726/exe
   pwdx 6726

   
   
   

Тут много нюансов и ответить однозначно сложно. Как уже написал Иван Шумов фреймворк - это инструмент. Каждый инструмент подбирается под конкретную задачу:

• СMS - система управления сайтом (Wordpress, Joomla и т.д.). Создан для простого и удобного управления сайтом (контентом). Как правило, доступен для работы простому пользователю, без знания языков программирования. Подойдёт для: простых сайтов, блогов, там где не требуется нагрузка и безопасность.
  
• RAD framework (Yii2) - фреймворк для быстрой разработки. RAD Фреймворк имеет, монолитную и связанную архитектуру. Он является антипаттенрном и позволяет вам делать всё что угодно, лишь бы вы быстро собрали свой проект. (Используется паттерн Table First - спроектировали базу и по схеме сгенерировали модели данных). При этом Вам никто не говорит, что он не может использоваться для серьёзных проектов. Например, DNS..
  
• Компонентные фреймворки (Symfony, Laravel). Это фреймворки, которые разделены на независимые компоненты, которые вы можете подключать к своему проекту при необходимости. В самом фреймворке заложен только необходимый минимум, а всё остальное вынесено в компоненты. Эти компоненты могут использоваться (или не использоваться). Могут использоваться для другого фреймворка (сам Yii2 использует компоненты симфони). Doctirine, которая позволяет вам забыть о базе данных и сосредоточиться на коде. Фреймворк задаёт вам некий стиль, некую структуру и типизацию и требует более хорошего и обдуманного кодинга. Например, при использовании twig вы не сможете сделать запрос в view. Чего нельзя сказать про Yii. Вы там можете построить хорошую бизнес логику, что и встречается...
  
• Микрофреймворки (Slim). В таких фреймворках заложен самый минимум, а всё остальное программист должен искать или писать самостоятельно, выстраивать свою архитектуру приложения. Он легкий и простой. Кто-то и Symfony относит к микрофреймворкам. Тут меня многие могут упрекнуть. Подойдет для очень простых, гибких, легких приложений, например, микросервисов. Фреймворк не задает вам никаких правил и архитектуры. Вы должны сами продумать все детали приложения. Где-то используете twig, где то Data Mapper, где-то ActiveRecord. Для работы с таким фреймворком требуется много знаний и опыта. Так как вам всё придется делать самому. Здесь за вас никто не подумал.
  

Что же для чего выбрать?
Решать вам исходя из конкретной задачи. Здесь нет понятия хуже/лучше. Чтобы что-то выбрать нужно на каждом попробовать собрать пару проектов. Тогда и будет понимание когда и что выбирать. Это как автомобиль. Какой лучше BMW или LADA? Оба автомобиля, но каждый для своей аудитории, по своим потребностям, для своих задач.

Почему другие говорят что Yii2 плохой?

• 2 версия морально устарела. Это не значит что ВЕСЬ фреймворк плохой, просто им давно никто не занимался. Сейчас идет разработка Yii3, которая многократно лучше 2 версии, но 3 версия доступна только в демо. Поэтому, если хочется писать НОВЫЙ проект на Yii, то я бы не стал выбирать 2 версию. Можете подождать Yii3, но никто не знает когда будет релиз. Можете начать писать используя Yii3-demo, но там может всё поменяться к моменту релиза.
  
• Он монолитный. Если вам требуется сделать проект используя много приложений с разными компонентами, то пойдёте по пути Advanced шаблона, где каждое приложение будет папкой: backend, forntend, console. Однако при большой нагрузке вам потребуется разносить приложения. Тогда ваш core будет дублироваться во всех приложениях. Там будет то, что вам даже не требуется. Потому что Yii2 монолит.
  
• В Yii2 используется Actvie Record. AR - это не плохо. Его многие любят, многие ценят и хвалят. Но для больших проектов он предоставляет неудобства. Например, при изменении поля в базе данных - приходится менять все свойства и надеяться что везде поменяли, так как в GrigView используется магия, при получение значений из модели 'value' => 'profile.last_name'. Так же нельзя сделать свойства модели (сущности), приватными. Из-за чего состояние модели можно изменить где угодно и вы никак не проконтролируете это.
  
• Много абстракции, которую не распознает редактор. Например, вы можете вызвать в контроллере Yii::$app->user->id. Вам приходится делать докблок, что User это common/auth/Identity, а не yii/web/User
  

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

1. Админу - админово. Поставить, завести юзеров, раздать права, создать базы. Уметь забэкапить БД, таблицу и восстановить ее средствами phpmyadmin, например. Уметь выполнить скрипт по созданию структуры таблиц "изнутри" консоли mysql, прочитать его вывод, найти ошибки, исправить (это как правило, отсутствующая либо наоборот присутствующая БД/таблица). Все, необходимое для того, чтобы приложение работало.
2. Изучение различий (при наличии например пакетов последних версий обеих типов). Наличие пакета под нужный дистриб, архитектуру, версию etc.
3. Читать маны. Пробовать. Документации много, но к сожалению, нигде не сказано "Вы покрутите этот параметр и вот это изменится вот на столько" - потому что задачи у всех разные
4. Правильным действием является прежде всего бэкап БД непосредственно перед обновлением :)
5. Не всегда. Если обновление движка потянет за собой обновление еще чего-нибудь, есть шанс, что например часть сайта после такого обновления просто не заработает :) Поэтому - бэкап, бэкап и еще баз бэкап!
6. По принципу необходимости для задачи всех фишек InnoDB. БД c небольшими таблицами, в которых например частичные блокировки не нужны - проще будет держать на MyISAM - он быстрее, его бэкап проще.

1. Смотря какой уровень. Стандартно - это установить MySQL, выдать права, создать БД/Таблицу с нужной кодировкой. Не только MySQL касается. Сейчас от неё уходят на MariaDB и PostgreSQL

2. MariaDB - лучше. И более открыта. И хороший дебаггер. MySQL - анахранизм. А лучше PostgreSQl и noSQL

3. Смотри англоязычные ресурсы. Заодно подтянешь и английский. все самые актуальные маны - там. Еще можешь глянуть в настройках всяких Линуксов, того же RHEL обычно там подробно.

4. Работает - не трогай.

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

6. По принципу рекомендуемых приложением. Если, например, к вики - системе указан InnoDB - значит InnoDB.

7. Если ты не БД - разработчик, то многого в базе тебе не нужно. Только умения поднять, провести первоначальную настройку и уметь делать дебаг. Оптимизации и т.д. Все потом.

Книги:
https://oz.by/books/more10295749.html
https://www.amazon.com/Mastering-MariaDB-Federico-...

1. Есть DBA - ничего. Нет DBA - все.
2. Религия в основном.
3. Читать документацию. Пробовать.
4. Бекап перед апдейтом всегда.
5. Сравнивать самому на типичных для выбранного проекта нагрузках.
6. От задач отталкиваться. Вроде как MyISAM быстрее на запись.
7. Гугл, маны и практика.

https://asp24.ru/mikrotik/opciya-random-v-firewall...

Есть разные подходы к пониманию смысла этих вещей.
Entities чаще всего используются в контексте DDD-подхода. Там это означает то, что объект может изменять свое состояние (фигура может менять цвет, стакан может заполняться и тд). Супротив Entities выступают т.н. ValueObject, которые используются только для чтения и менять свое состояние не могут.
И те, и другие используются в бизнес-логике приложения и генерируются либо хранилищами (storage), либо сервисам (в зависимости от выбранного подхода).

В контексте же Yii понятие Entity не применяется. ибо там структурной единицей бизнес-логики выступают экземпляры ActiveRecord чаще всего (сам фреймворк к этому располагает), либо, иногда, наследники Model.

Главное - это то, что сущность не обязательна должна сохраняться as is, т.е. иметь четкую проекцию в БД, ибо сущностью может выступать экземпляр паттерна Композит - все зависит от хранилища/сервиса, который это дело будет "CRUD'ить".

$modules = glob( 'modules*', GLOB_ONLYDIR );
$modules_folder = array_shift( $modules );

Между нами, есть ещё один странный способ проверки существования каталога.