estic

Во-первых, работа в реальном времени. Во-вторых, есть такие вещи, которые не воспроизводятся в копии даже при полном копировании (простейший пример - нагрузка на сервер).

Я тоже обычно работаю по SSH и т.п. Но ведь к PMA на сервере можно подключиться таким же способом. По возможности "посредников" лучше размещать ближе к "телу", независимо от того, реализуют ли они прикладной интерфейс или пользовательский.

...Или вы боитесь, что сама PMA может содержать вредоносный код?

Вы поняли неправильно. Я Web-программист. Также занимаюсь администрированием MySQL, MS SQL (Server). SQL-аналитика, естественно, прилагается.

Так я и говорю, что PMA - не ваш инструмент. Я тоже могу редко используемую (с непредсказуемой периодичностью использования) Web-панель "снести" на сервере, а в случае крайней необходимости подключить ее удаленно (если панель легко подключить удаленно и к ФС сервера). Но если вам требуется работать с подобными панелями с определенной периодичностью, то лучше их держать на сервере. Или периодически устанавливать и "сносить" 😀

Административные Web-панели вообще не используете на "проде"? Десктопные что ли панели?

Я уже давно понял, что для вас PMA - это мусор. Можете думать о PMA в данном контексте, как о любой другой Web-панели (т.е. панели с пользовательским Web-интерфейсом). Может, так будет проще понять. "Прокладку" лучше держать ближе к телу, когда она бывает нужна.

Не создает, если размещена на локальном интерфейсе (loopback, etc.). Ест ресурсы, в основном когда работает. А работает не часто. (Еще прошлый раз хотел пошутить: "Место на диске решили сэкономить?" Но похоже тут все серьезно 😀) Если бы речь шла о каком-то десктопном клиенте, здесь бы, естественно, вопросов не было. Но это Web-панель на типичном серверном языке. Ее можно было бы разместить удаленно, если бы ваш компьютер использовался как Web-сервер в VPN. Хотя даже в VPN лучше держать PMA и базы данных в одном сегменте.

Я, например, понимаю. Но PMA лучше держать на том же сервере, что и базу данных (или хотя бы в той же сети, если у вас все распределено по разным серверам). Зачем ее "носить с собой"?

Вам предложили подключить к ней PMA по SSH. Т.е. прямой доступ остается локальным на сервере. Не безопасно "выставлять панели наружу", о чем я вам ранее писал.

Можно и старый каталог C:\Certbot использовать. Только симлинки в C:\Certbot\live\domain.tld нужно восстановить вместо копий файлов. Пример для командного файла:

mklink C:\Certbot\live\%1\cert.pem C:\Certbot\archive\%1\cert%2.pem
mklink C:\Certbot\live\%1\chain.pem C:\Certbot\archive\%1\chain%2.pem
mklink C:\Certbot\live\%1\fullchain.pem C:\Certbot\archive\%1\fullchain%2.pem
mklink C:\Certbot\live\%1\privkey.pem C:\Certbot\archive\%1\privkey%2.pem

Первый параметр - основной домен, второй - номер последнего выпуска сертификата.

Если сейчас используется ZeroSSL, то проще выпустить Let's Encrypt полной командой, как писали выше. Но старые файлы все равно лучше разместить на своих местах, чтобы выпускать под старым аккаунтом.

Про сервер на Windows 7 для Web-а не понял. Нужно использовать серверную ОС. При этом сертификаты можно выпускать Certbot-ом на домашней ОС и вручную устанавливать на сервер аналогично ZeroSSL. Для автоматической валидации можно использовать мой сервис вместо использования "аутентификатора" и записи чего-либо на ваш сервер в процессе валидации.

Используйте компонентный подход. Многие фреймворки официально позволяют выборочно использовать свои библиотеки, например тот же Symfony. Использовать только какой-то определенный фреймворк - это сильно себя ограничивать. Так поступают только новички или адепты, у которых на все одно решение.

Совсем уж "зоопарк" тоже устраивать не нужно, а то "натянете" много лишнего и "конфликтного".

PHP-фреймворк для фронтэнда? 😊

Да. Про PMA по ссылке в панели не помню (наверное, тоже). Я ispmanager и т.п. не использую за ненадобностью. PMA отдельно устанавливаю, когда нужно. Обычно использую HTTP, т.к. этот трафик во что-то завернут 😉