- Информация о материале
- Автор: Геннадий Едиг
- Категория: Web, Python, Ubuntu, Joomla, Virtuemart
- Просмотров: 35
Печать из Windows 10/11 на принтере HP LaserJet 1100 возможна и в 2025 году. Для этого достаточно иметь компьютер с LPT-портом. Это может быть PCI-плата с LPT, как у меня, или Ubuntu из коробки, которая не требует дополнительных настроек. После установки можно сразу приступать к печати, следуя описанным ниже шагам.
Это руководство описывает процесс установки и настройки принтера HP LaserJet 1100 на сервере Ubuntu 24.04, подключенного через LPT-порт, и превращения сервера в принт-сервер для сетевого доступа, включая печать с Windows 10. Используется драйвер Gutenprint для локальной печати и CUPS для сетевого доступа.
Предварительные требования
- Сервер Ubuntu 24.04 с root-доступом.
- Принтер HP LaserJet 1100, подключенный через LPT-порт (/dev/lp0).
- Сеть со статическим IP (например, 192.168.0.200).
- Клиент Windows 10 для сетевой печати.
Пошаговая инструкция
Подробнее: Установка HP LaserJet 1100 на сервер Ubuntu как принт-сервер в 2025 году :)
- Информация о материале
- Автор: Геннадий Едиг
- Категория: Web, Python, Ubuntu, Joomla, Virtuemart
- Просмотров: 27
Описание задачи
Задача заключалась в настройке сайта на VPS-сервере с ISPmanager, чтобы приложение на FastAPI было доступно по адресу https://dwc.ru/
, заменив заглушку index.html
. Изначально FastAPI-приложение работало по адресу http://dwc.ru:8000/frontend/index.html
, но не поддерживало HTTPS по адресу https://dwc.ru:8000/frontend/index.html
из-за отсутствия безопасного соединения. Необходимо было сделать так, чтобы фронтенд интернет-магазина отображался по https://dwc.ru/
с поддержкой HTTPS.
Изначальная конфигурация системы
Начальная конфигурация включала:
- Сервер: VPS с ISPmanager, где Nginx выступал фронтенд-сервером, а Apache — бэкенд-сервером на порту 8080.
- Конфигурация Nginx (
/etc/nginx/vhosts/www-root/dwc.ru.conf
):- Слушал порты
192.168.0.31:80
и192.168.0.31:443
(SSL). - Проксировал запросы на Apache (
http://127.0.0.1:8080
). - Обрабатывал статические файлы и PHP-скрипты с fallback на Apache.
- Использовал SSL-сертификаты Let’s Encrypt (
/var/www/httpd-cert/www-root/dwc.ru_le1.crtca
иdwc.ru_le1.key
). - Перенаправлял
www.dwc.ru
наdwc.ru
и HTTP на HTTPS.
- Слушал порты
- Конфигурация Apache (
/etc/apache2/vhosts/www-root/dwc.ru.conf
):- VirtualHost на
127.0.0.1:8080
, обслуживающий корневую директорию/var/www/www-root/data/www/dwc.ru
. - Настроен для обработки PHP и статических файлов.
- Отображал заглушку
index.html
в корневой директории.
- VirtualHost на
- Приложение FastAPI:
- Работало на
http://127.0.0.1:8000
. - Обслуживало фронтенд по адресу
/frontend/index.html
, доступному черезhttp://dwc.ru:8000/frontend/index.html
. - Не было интегрировано с Nginx или Apache, что делало его недоступным по HTTPS на корневом домене.
- Работало на
При обращении к https://dwc.ru/
отображалась заглушка index.html
, а приложение FastAPI было доступно только через незащищённый порт 8000, что не подходило для продакшена.
Проблемы и процесс решения
Основные проблемы:
- Заглушка: Файл
index.html
в/var/www/www-root/data/www/dwc.ru/
отображался вместо фронтенда FastAPI. - HTTPS: Приложение FastAPI не было настроено для HTTPS, и прямой доступ к порту 8000 через HTTPS не работал.
- Ошибки Nginx: Первоначальные попытки проксирования на FastAPI приводили к синтаксическим ошибкам в директивах
proxy_set_header
и некорректной обработке корневого пути (/
). - Обработка корня: FastAPI возвращал JSON-ответ (
{"message":"Welcome to DWC.ru API"}
) для корневого пути, вместо фронтенда по адресу/frontend/index.html
.
Шаги решения
- Создание резервных копий:
Созданы резервные копии конфигураций Nginx и Apache для возможности восстановления:
mkdir -p ~/backups/configs sudo cp /etc/nginx/vhosts/www-root/dwc.ru.conf ~/backups/configs/dwc.ru.nginx.bak sudo cp /etc/apache2/vhosts/www-root/dwc.ru.conf ~/backups/configs/dwc.ru.apache.bak
- Отключение заглушки:
Перемещён файл
index.html
, чтобы он не отображался:sudo mv /var/www/www-root/data/www/dwc.ru/index.html /var/www/www-root/data/www/dwc.ru/index.html.bak
- Обновление конфигурации Nginx:
Изменён файл
/etc/nginx/vhosts/www-root/dwc.ru.conf
для проксирования запросов на FastAPI (http://127.0.0.1:8000
) и отображения фронтенда в корне.Столкнулись с ошибками в директивах
proxy_set_header
(например,invalid number of arguments
), вызванными некорректными значениями (например,proxy_set_header Host ;
).Итеративно исправляли конфигурацию, обеспечив правильный синтаксис (например,
proxy_set_header Host $host;
).Добавлена обработка корневого пути (
location = /
) для прямой отдачи/frontend/index.html
, а запросы к API (/api/
) перенаправлялись на FastAPI. - Финальная конфигурация Nginx:
Окончательная конфигурация явно отображает фронтенд для корня и проксирует запросы API на FastAPI:
server { listen 192.168.0.31:80; server_name dwc.ru www.dwc.ru; return 301 https://dwc.ru$request_uri; } server { listen 192.168.0.31:443 ssl; server_name dwc.ru; ssl_certificate "/var/www/httpd-cert/www-root/dwc.ru_le1.crtca"; ssl_certificate_key "/var/www/httpd-cert/www-root/dwc.ru_le1.key"; ssl_ciphers EECDH:+AES256:-3DES:RSA+AES:!NULL:!RC4; ssl_prefer_server_ciphers on; ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; ssl_dhparam /etc/ssl/certs/dhparam4096.pem; access_log /var/www/httpd-logs/dwc.ru.access.log; error_log /var/www/httpd-logs/dwc.ru.error.log notice; # Serve frontend for root location = / { root /var/www/www-root/data/www/dwc.ru; try_files /frontend/index.html =404; add_header Cache-Control "no-cache, no-store, must-revalidate"; add_header Pragma "no-cache"; add_header Expires "0"; } # Proxy API requests to FastAPI location /api/ { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } # Serve static frontend files location /frontend/ { alias /var/www/www-root/data/www/dwc.ru/frontend/; try_files $uri $uri/ /frontend/index.html; add_header Cache-Control "no-cache, no-store, must-revalidate"; add_header Pragma "no-cache"; add_header Expires "0"; } gzip on; gzip_comp_level 5; gzip_disable "msie6"; gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript image/svg+xml; ssi off; } server { listen 192.168.0.31:443 ssl; server_name www.dwc.ru; ssl_certificate "/var/www/httpd-cert/www-root/dwc.ru_le1.crtca"; ssl_certificate_key "/var/www/httpd-cert/www-root/dwc.ru_le1.key"; ssl_ciphers EECDH:+AES256:-3DES:RSA+AES:!NULL:!RC4; ssl_prefer_server_ciphers on; ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; ssl_dhparam /etc/ssl/certs/dhparam4096.pem; return 301 https://dwc.ru$request_uri; }
Применение конфигурации:
sudo nginx -t sudo systemctl restart nginx
- Отключение Apache:
Поскольку Apache больше не требовался (его роль заменил FastAPI), VirtualHost был отключён:
sudo mv /etc/apache2/vhosts/www-root/dwc.ru.conf ~/backups/configs/dwc.ru.apache.disabled sudo systemctl restart apache2
- Тестирование и отладка:
Проверяли сайт с помощью:
curl -L https://dwc.ru/
Изначально возникала ошибка
500 Internal Server Error
из-за некорректной директивыalias
для корневого пути. Заменилиalias
наroot
иtry_files
.Проверяли работу FastAPI:
curl http://127.0.0.1:8000/frontend/index.html
Анализировали логи ошибок:
sudo tail -f /var/www/httpd-logs/dwc.ru.error.log sudo tail -f /var/www/httpd-logs/dwc.ru.access.log
- Очистка кэша:
Очистили кэш Nginx для исключения проблем с кэшированием:
sudo rm -rf /var/cache/nginx/* sudo systemctl restart nginx
Изменения относительно первоначальной настройки
По сравнению с изначальной конфигурацией были внесены следующие изменения:
- Удаление заглушки: Файл
/var/www/www-root/data/www/dwc.ru/index.html
перемещён вindex.html.bak
. - Реконфигурация Nginx:
- Заменено проксирование на Apache (
http://127.0.0.1:8080
) проксированием на FastAPI (http://127.0.0.1:8000
) для запросов к/api/
. - Добавлена отдача
/frontend/index.html
для корневого пути (/
) с использованиемroot
иtry_files
. - Настроена обработка статических файлов фронтенда из
/var/www/www-root/data/www/dwc.ru/frontend/
. - Добавлены заголовки управления кэшем для предотвращения проблем с кэшированием.
- Сохранена поддержка SSL с сертификатами Let’s Encrypt.
- Заменено проксирование на Apache (
- Отключение Apache: Конфигурация VirtualHost перемещена в резервную копию, так как Apache больше не нужен.
- Интеграция FastAPI: FastAPI корректно обрабатывает API-запросы, а фронтенд для корня обслуживается напрямую через Nginx.
Итоговый результат
Интернет-магазин на базе FastAPI теперь доступен, временно доступен, по адресу https://dwc.ru/
, отображая фронтенд (/frontend/index.html
) с каталогом товаров. Сайт использует HTTPS с сертификатами Let’s Encrypt, а запросы к API (/api/
) корректно проксируются на FastAPI. Заглушка больше не отображается, конфигурация стабильна, а резервные копии позволяют восстановить систему при необходимости.
Решение потребовало тщательной отладки ошибок синтаксиса Nginx, настройки обработки статических файлов и интеграции с FastAPI, обеспечив удобный доступ пользователей к интернет-магазину.
- Информация о материале
- Автор: Геннадий Едиг
- Категория: Web, Python, Ubuntu, Joomla, Virtuemart
- Просмотров: 23
Сегодня хочу поделиться важным наблюдением, которое сэкономит вам кучу нервов при работе с ISPmanager на хостинге reg.ru. Речь пойдёт о коварном поведении панели управления при создании SSL-сертификатов.
Почему это происходит?
- Информация о материале
- Автор: Геннадий Едиг
- Категория: Web, Python, Ubuntu, Joomla, Virtuemart
- Просмотров: 28
Был у меня VPS сервер на котором было несколько сайтов размещенных с помощью isp manager.
В какой-то момент я решил повысить тариф, чо привело к порче isp manager.
Со слов поддержки причина в установленной мной библиотеки которая сломала isp manager и удаление которой не поможет восстановить isp manager.
В итоге я проверил все и выходит что причина действительно в этой библиотеке, но как оказалось моя ubuntu 20 устараела и пытаться натянуть для восстановления isp manager поверх старого не имеет смысл, так как все-равно нужно перебираться на другой сервер.
В итоге очередной переезд и на этот раз без веб интерфейса.
1. Копируем файлы сайтов
2. Пишем код на питоне который возьмет данные для доступа к базе из конфигурационных файлов joomla и wordpress и сделает бэкап сайтов
3. Сохраняем все что связано с Python
4. Не забываем про файлы systemd
5. Забываем о мелочах типа особых настроек серверов и почты
Переезжаем...
Может добавлю что-то.
Если всё суда добавить то будет объемный труд. Но надо добавить :)
Должно получится примерно так:
Детальный план переезда с VPS (сломанный ISPmanager) на новый сервер
1. Подготовка перед переездом
- Резервное копирование ВСЕГО (даже если что-то сломано):
- tar -czvf backup_$(date +%F).tar.gz /var/www/ /etc/nginx/ /etc/apache2/ /home/ /etc/mysql/ /etc/php/
- Проверить, что бэкапы целы (du -sh backup_*.tar.gz, попробовать распаковать в /tmp).
- Можно использовать rsync для копирования на другой сервер или локальный ПК.
2. Копирование файлов сайтов
- Ручное копирование (если ISPmanager сломан):
- bashrsync -avz --progress /var/www/ user@new-server:/var/www/ rsync -avz --progress /home/user/ user@new-server:/home/user/
- Copy
- Проверка прав (chown -R www-data:www-data /var/www/).
3. Автоматизация бэкапов баз данных (Python-скрипт)
Пример кода для резервирования MySQL:
python
Copy
import os import subprocess import json from pathlib import Path def get_db_credentials(config_path, cms_type): if cms_type == "wordpress": with open(config_path / "wp-config.php") as f: content = f.read() db_name = content.split("DB_NAME', '")[1].split("'")[0] db_user = content.split("DB_USER', '")[1].split("'")[0] db_pass = content.split("DB_PASSWORD', '")[1].split("'")[0] db_host = content.split("DB_HOST', '")[1].split("'")[0] return db_name, db_user, db_pass, db_host elif cms_type == "joomla": with open(config_path / "configuration.php") as f: content = f.read() db_name = content.split("public $db = '")[1].split("'")[0] db_user = content.split("public $user = '")[1].split("'")[0] db_pass = content.split("public $password = '")[1].split("'")[0] db_host = content.split("public $host = '")[1].split("'")[0] return db_name, db_user, db_pass, db_host def backup_database(db_name, db_user, db_pass, db_host, output_dir): os.makedirs(output_dir, exist_ok=True) dump_file = f"{output_dir}/{db_name}_backup.sql" cmd = f"mysqldump -h {db_host} -u {db_user} -p'{db_pass}' {db_name} > {dump_file}" subprocess.run(cmd, shell=True, check=True) print(f"Backup saved to: {dump_file}") if __name__ == "__main__": websites = [ {"path": "/var/www/site1", "cms": "wordpress"}, {"path": "/var/www/site2", "cms": "joomla"} ] for site in websites: config_path = Path(site["path"]) db_name, db_user, db_pass, db_host = get_db_credentials(config_path, site["cms"]) backup_database(db_name, db_user, db_pass, db_host, "/backups/db")
4. Перенос Python-окружения
- Экспорт зависимостей:
- bashpip freeze > requirements.txt rsync -avz --progress /path/to/virtualenv/ user@new-server:/path/to/virtualenv/
- Copy
- Проверка версии Python (на новом сервере):
- bashpython3 --version sudo apt install python3-venv # если нужно
- Copy
5. Systemd-юниты и Cron-задачи
- Копирование служб:
- bashrsync -avz --progress /etc/systemd/system/my_service.service user@new-server:/etc/systemd/system/
- Copy
- Активация на новом сервере:
- bashsudo systemctl daemon-reload sudo systemctl enable my_service sudo systemctl start my_service
- Copy
- Крон:
- bashcrontab -l > cron_backup.txt scp cron_backup.txt user@new-server:~/ # На новом сервере: crontab cron_backup.txt
- Copy
6. Восстановление почты (если нужно)
- Копирование Postfix/Dovecot:
- bashrsync -avz --progress /etc/postfix/ user@new-server:/etc/postfix/ rsync -avz --progress /etc/dovecot/ user@new-server:/etc/dovecot/
- Copy
- Проверка DNS-записей (MX, SPF, DKIM).
7. Настройка веб-сервера (Nginx/Apache)
- Без ISPmanager придется вручную:
- bashsudo apt install nginx mysql-server php-fpm sudo cp /backups/nginx/sites-available/* /etc/nginx/sites-available/ sudo ln -s /etc/nginx/sites-available/site.conf /etc/nginx/sites-enabled/ sudo nginx -t # проверка конфига sudo systemctl restart nginx
- Copy
8. Проверка после переезда
- Тест сайтов: curl -I https://ваш-сайт (коды 200, 301).
- Логи: tail -f /var/log/nginx/error.log.
- Базы данных: подключиться и проверить таблицы.
Что можно добавить?
- Мониторинг (например, netdata или prometheus + grafana).
- Автоматические бэкапы (например, borgbackup + rclone на облако).
- Infrastructure as Code (Ansible для настройки сервера).
- Docker (чтобы изолировать сервисы и упростить миграции).
Говорят ISP manager сам делает существенную часть этой работы...
- Информация о материале
- Автор: Геннадий Едиг
- Категория: Web, Python, Ubuntu, Joomla, Virtuemart
- Просмотров: 48
Мне нравится автоматизировать рутинные задачи. Недавно я решил создать несколько парсеров для сбора данных с веб-сайтов, чтобы делиться новостями и статьями в социальных сетях. В этом мне помогал ИИ — современный инструмент, который пишет код быстрее, чем я успеваю сформулировать задачу. Однако в процессе я столкнулся с проблемой, которую ИИ не всегда замечает: постоянное потребление памяти WebDriver (например, Firefox через Selenium) даже в простое. Эта статья — мой рассказ о том, как ИИ ускоряет разработку, но почему неквалифицированным программистам вроде меня нужно быть внимательнее, чтобы замечать такие подводные камни.
Почему я выбрал ИИ для программирования
Как человек без глубоких знаний в разработке, я ценю ИИ за его способность создавать сложный код буквально за минуты. Хочешь парсер для новостного сайта? Задаёшь вопрос, указываешь, что нужно (например, Selenium для динамических страниц), и получаешь готовый скрипт с логированием, обработкой ошибок и даже комментариями. Для меня это как волшебство: я описываю задачу на русском, а ИИ выдаёт Python-код, который в 90% случаев работает с первого раза.
В моём случае я хотел написать два парсера:
- Один собирал статьи и видео с моего канала на Дзене для публикации в Telegram и ВКонтакте.
- Другой парсил новостные сайты, ища материалы с ключевыми словами вроде. Просто чтобы быть в курсе определенных событий.
Оба парсера использовали Selenium с Firefox в headless-режиме, чтобы обрабатывать динамический контент. ИИ быстро выдал рабочие скрипты, которые находили ссылки, проверяли даты и отправляли сообщения. Всё выглядело идеально — пока я не заметил, что сервер начал задыхаться.