Подборка самого интересного, полезного и значимого хоть как-то связанного со мной

Установка HP LaserJet 1100 на сервер Ubuntu как принт-сервер в 2025 году :)

Информация о материале
Автор: Геннадий Едиг
Категория: 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 году :)

Решение проблемы настройки HTTPS для сайта на FastAPI

Информация о материале
Автор: Геннадий Едиг
Категория: 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 в корневой директории.
  • Приложение 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.

Шаги решения

  1. Создание резервных копий:

    Созданы резервные копии конфигураций 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
  2. Отключение заглушки:

    Перемещён файл 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
  3. Обновление конфигурации 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.

  4. Финальная конфигурация 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
  5. Отключение Apache:

    Поскольку Apache больше не требовался (его роль заменил FastAPI), VirtualHost был отключён:

    sudo mv /etc/apache2/vhosts/www-root/dwc.ru.conf ~/backups/configs/dwc.ru.apache.disabled
sudo systemctl restart apache2
  6. Тестирование и отладка:

    Проверяли сайт с помощью:

    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
  7. Очистка кэша:

    Очистили кэш 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: Конфигурация VirtualHost перемещена в резервную копию, так как Apache больше не нужен.
  • Интеграция FastAPI: FastAPI корректно обрабатывает API-запросы, а фронтенд для корня обслуживается напрямую через Nginx.

Итоговый результат

Интернет-магазин на базе FastAPI теперь доступен, временно доступен, по адресу https://dwc.ru/, отображая фронтенд (/frontend/index.html) с каталогом товаров. Сайт использует HTTPS с сертификатами Let’s Encrypt, а запросы к API (/api/) корректно проксируются на FastAPI. Заглушка больше не отображается, конфигурация стабильна, а резервные копии позволяют восстановить систему при необходимости.

Решение потребовало тщательной отладки ошибок синтаксиса Nginx, настройки обработки статических файлов и интеграции с FastAPI, обеспечив удобный доступ пользователей к интернет-магазину.

Тихий подвох ISPmanager: как не попасть на самоподписанный сертификат вместо Let's Encrypt

Информация о материале
Автор: Геннадий Едиг
Категория: Web, Python, Ubuntu, Joomla, Virtuemart
Просмотров: 23

Сегодня хочу поделиться важным наблюдением, которое сэкономит вам кучу нервов при работе с ISPmanager на хостинге reg.ru. Речь пойдёт о коварном поведении панели управления при создании SSL-сертификатов.

Главное правило: Никогда не включайте редирект с HTTP на HTTPS до получения Let's Encrypt сертификата! Иначе вместо настоящего SSL вы получите молчаливую подмену на самоподписанный сертификат.

Почему это происходит?

Подробнее: Тихий подвох ISPmanager: как не попасть на самоподписанный сертификат вместо Let's Encrypt

Об особенностях переноса сайтов с одного хостинга на другой без isp manager

Информация о материале
Автор: Геннадий Едиг
Категория: 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. Восстановление почты (если нужно)

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 сам делает существенную часть этой работы...

Как ИИ помогает в программировании, но упускает важные детали: мой опыт с парсерами и WebDriver

Информация о материале
Автор: Геннадий Едиг
Категория: Web, Python, Ubuntu, Joomla, Virtuemart
Просмотров: 48

Мне нравится автоматизировать рутинные задачи. Недавно я решил создать несколько парсеров для сбора данных с веб-сайтов, чтобы делиться новостями и статьями в социальных сетях. В этом мне помогал ИИ — современный инструмент, который пишет код быстрее, чем я успеваю сформулировать задачу. Однако в процессе я столкнулся с проблемой, которую ИИ не всегда замечает: постоянное потребление памяти WebDriver (например, Firefox через Selenium) даже в простое. Эта статья — мой рассказ о том, как ИИ ускоряет разработку, но почему неквалифицированным программистам вроде меня нужно быть внимательнее, чтобы замечать такие подводные камни.

Почему я выбрал ИИ для программирования

Как человек без глубоких знаний в разработке, я ценю ИИ за его способность создавать сложный код буквально за минуты. Хочешь парсер для новостного сайта? Задаёшь вопрос, указываешь, что нужно (например, Selenium для динамических страниц), и получаешь готовый скрипт с логированием, обработкой ошибок и даже комментариями. Для меня это как волшебство: я описываю задачу на русском, а ИИ выдаёт Python-код, который в 90% случаев работает с первого раза.

В моём случае я хотел написать два парсера:

  1. Один собирал статьи и видео с моего канала на Дзене для публикации в Telegram и ВКонтакте.
  2. Другой парсил новостные сайты, ища материалы с ключевыми словами вроде. Просто чтобы быть в курсе определенных событий.

Оба парсера использовали Selenium с Firefox в headless-режиме, чтобы обрабатывать динамический контент. ИИ быстро выдал рабочие скрипты, которые находили ссылки, проверяли даты и отправляли сообщения. Всё выглядело идеально — пока я не заметил, что сервер начал задыхаться.

Подробнее: Как ИИ помогает в программировании, но упускает важные детали: мой опыт с парсерами и WebDriver

  1. Питонизация процессов в Joomla: автоматизация экспорта данных в VK Маркет
  2. Питонизация Joomla: как Python может похоронить традиционные CMS
  3. Установка SSL-сертификата AlphaSSL в ISPmanager (Reg.ru)
  4. C чего начать программирование python в 2025 году

Страница 1 из 10