Информация
Услуги
  • Внедрение
  • Настройка
  • Поддержка
  • Ремонт
Контакты
Оплата
Новости
Доставка
Загрузки
Форум
Настройка
    info@proxmox.su
    +7 (495) 320-70-49
    Заказать звонок
    Аспро: ЛайтШоп
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Аспро: ЛайтШоп
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Аспро: ЛайтШоп
    Телефоны
    +7 (495) 320-70-49
    Заказать звонок
    0
    0
    0
    Аспро: ЛайтШоп
    • +7 (495) 320-70-49
      • Назад
      • Телефоны
      • +7 (495) 320-70-49
      • Заказать звонок
    • info@proxmox.su
    • Москва, Бакунинская улица, 69с1
    • Пн-Пт: 09-00 до 18-00
      Сб-Вс: выходной
    • 0 Сравнение
    • 0 Избранное
    • 0 Корзина
    Главная
    Форум
    Proxmox Виртуальная Среда
    Разрешение запрещено — недействительный билет PVE (401).

    Форумы: Proxmox Виртуальная Среда, Proxmox Backup Server, Proxmox Mail Gateway, Proxmox Datacenter Manager
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    Разрешение запрещено — недействительный билет PVE (401)., Proxmox Виртуальная Среда
     
    mailinglists
    Guest
    #1
    0
    11.11.2020 18:51:00
    Привет, ребята! В PM 6 я получил "permission denied - invalid PVE ticket (401)" при использовании WEB GUI на одном из узлов кластера. Меня выбрасывало из WEB GUI сразу же, как только я начинал просматривать проблемный узел через HTTP, даже если я изначально подключался к другому узлу. Другие узлы работают нормально. Я решил проблему, перезапустив сервисы: root@p37:~# systemctl restart pvedaemon pveproxy Возможно, это баг. Кажется, что я не один с этой проблемой, но, полагаю, суть этого сообщения на форуме — поделиться решением, которое сработало для меня.

    Вот информация о версии:

    Code:
    proxmox-ve: 6.2-2 (running kernel: 5.4.65-1-pve)
    pve-manager: 6.2-12 (running version: 6.2-12/b287dd27)
    pve-kernel-5.4: 6.2-7
    pve-kernel-helper: 6.2-7
    pve-kernel-5.4.65-1-pve: 5.4.65-1
    pve-kernel-5.4.34-1-pve: 5.4.34-2
    ceph-fuse: 12.2.11+dfsg1-2.1+b1
    corosync: 3.0.4-pve1
    criu: 3.11-3
    glusterfs-client: 5.5-3
    ifupdown: 0.8.35+pve1
    ksm-control-daemon: 1.3-1
    libjs-extjs: 6.0.1-10
    libknet1: 1.16-pve1
    libproxmox-acme-perl: 1.0.5
    libpve-access-control: 6.1-3
    libpve-apiclient-perl: 3.0-3
    libpve-common-perl: 6.2-2
    libpve-guest-common-perl: 3.1-3
    libpve-http-server-perl: 3.0-6
    libpve-storage-perl: 6.2-8
    libqb0: 1.0.5-1
    libspice-server1: 0.14.2-4~pve6+1
    lvm2: 2.03.02-pve4
    lxc-pve: 4.0.3-1
    lxcfs: 4.0.3-pve3
    novnc-pve: 1.1.0-1
    proxmox-backup-client: 0.9.0-2
    proxmox-mini-journalreader: 1.1-1
    proxmox-widget-toolkit: 2.3-1
    pve-cluster: 6.2-1
    pve-container: 3.2-2
    pve-docs: 6.2-6
    pve-edk2-firmware: 2.20200531-1
    pve-firewall: 4.1-3
    pve-firmware: 3.1-3
    pve-ha-manager: 3.1-1
    pve-i18n: 2.2-1
    pve-qemu-kvm: 5.1.0-3
    pve-xtermjs: 4.7.0-2
    qemu-server: 6.2-15
    smartmontools: 7.1-pve2
    spiceterm: 3.1-1
    vncterm: 1.6-2
    zfsutils-linux: 0.8.4-pve2
     
     
     
    Joris L.
    Guest
    #2
    0
    11.11.2020 19:37:00
    А это не из-за случайной очистки кэша или истечения времени сессии?
     
     
     
    fabian
    Guest
    #3
    0
    12.11.2020 09:31:00
    Обычно это связано с тем, что у PVE-ноды время стоит неверное.
     
     
     
    mailinglists
    Guest
    #4
    0
    13.11.2020 18:04:00
    У меня на узлах одинаковое время, они используют ntp. Это первое, что я проверил.
     
     
     
    mailinglists
    Guest
    #5
    0
    13.11.2020 18:05:00
    Нет, я пробовал разные браузеры, очищал кэш, использовал разные клиентские компьютеры... и так далее. Нигде не работало, а заработало везде после перезапуска этих сервисов на хосте.
     
     
     
    mailinglists
    Guest
    #6
    0
    19.11.2020 17:48:00
    Коллега получил те же ошибки, хотя у меня все работало. Кстати, он смог исправить это, вручную удалив куки. Перезагружать pve-шные штуки не нужно.
     
     
     
    mailinglists
    Guest
    #7
    0
    19.11.2020 18:22:00
    Теперь даже наша система мониторинга вылетает, а потом снова работает… что-то странное происходит… думаю, стоит открыть баг.
     
     
     
    mailinglists
    Guest
    #8
    0
    19.11.2020 18:27:00
    Проблемы были только с одним узлом, поэтому я перезапустил systemctl restart pvedaemon pveproxy на нем. Больше ошибок при входе нет, не в логах, не в нашей системе мониторинга, не на рабочих столах. Это точно баг. Стоит ли открывать баг-репорт? @fabian В качестве временного решения можно настроить cronjob, который будет перезапускать pvedaemon pveproxy каждые несколько часов...
     
     
     
    hosting
    Guest
    #9
    0
    19.11.2020 18:42:00
    Тоже столкнулся с такой же проблемой на одном из четырех нодов. Определённо, это ошибка.

    Code: proxmox-ve: 6.2-2 (running kernel: 5.4.65-1-pve)
    pve-manager: 6.2-15 (running version: 6.2-15/48bd51b6)
    pve-kernel-5.4: 6.2-7
    pve-kernel-helper: 6.2-7
    pve-kernel-5.3: 6.1-6
    pve-kernel-5.4.65-1-pve: 5.4.65-1
    pve-kernel-5.4.34-1-pve: 5.4.34-2
    pve-kernel-5.3.18-3-pve: 5.3.18-3
    pve-kernel-5.3.18-2-pve: 5.3.18-2
    pve-kernel-5.3.10-1-pve: 5.3.10-1
    ceph-fuse: 12.2.11+dfsg1-2.1+b1
    corosync: 3.0.4-pve1
    criu: 3.11-3
    glusterfs-client: 5.5-3
    ifupdown: residual config
    ifupdown2: 3.0.0-1+pve3
    ksm-control-daemon: 1.3-1
    libjs-extjs: 6.0.1-10
    libknet1: 1.16-pve1
    libproxmox-acme-perl: 1.0.5
    libpve-access-control: 6.1-3
    libpve-apiclient-perl: 3.0-3
    libpve-common-perl: 6.2-2
    libpve-guest-common-perl: 3.1-3
    libpve-http-server-perl: 3.0-6
    libpve-storage-perl: 6.2-9
    libqb0: 1.0.5-1
    libspice-server1: 0.14.2-4~pve6+1
    lvm2: 2.03.02-pve4
    lxc-pve: 4.0.3-1
    lxcfs: 4.0.3-pve3
    novnc-pve: 1.1.0-1
    proxmox-backup-client: 0.9.4-1
    proxmox-mini-journalreader: 1.1-1
    proxmox-widget-toolkit: 2.3-6
    pve-cluster: 6.2-1
    pve-container: 3.2-2
    pve-docs: 6.2-6
    pve-edk2-firmware: 2.20200531-1
    pve-firewall: 4.1-3
    pve-firmware: 3.1-3
    pve-ha-manager: 3.1-1
    pve-i18n: 2.2-2
    pve-qemu-kvm: 5.1.0-4
    pve-xtermjs: 4.7.0-2
    qemu-server: 6.2-18
    smartmontools: 7.1-pve2
    spiceterm: 3.1-1
    vncterm: 1.6-2
    zfsutils-linux: 0.8.4-pve2 Время на всех 4 нодах одинаковое/правильное.
     
     
     
    fabian
    Guest
    #10
    0
    20.11.2020 08:27:00
    Можешь, пожалуйста, глянуть логи pvedaemon и pveproxy, там вроде бы должно быть сообщение об обновлении аутентификационного ключа раз в день. Если вместо этого там предупреждение/ошибка, то, возможно, есть проблемы с pmxcfs.
     
     
     
    mailinglists
    Guest
    #11
    0
    20.11.2020 13:14:00
    В следующий раз, когда замечу, что кто-то выходит из системы, я поищу в syslog pveproxy и pvedaemon.
     
     
     
    Joris L.
    Guest
    #12
    0
    23.11.2020 09:17:00
    Ну вот, собственно. Перезапуск сервиса делает больше, чем просто это. Он также перезапускает сессии и генерирует новые ID. По сути, как будто чистишь куки. Не может ли быть так, что между браузером и сервисом стоит прокси, который обрезает или переписывает часть заголовка?
     
     
     
    fabian
    Guest
    #13
    0
    23.11.2020 09:22:00
    PVE не имеет серверной сессии состояния..
     
     
     
    Joris L.
    Guest
    #14
    0
    23.11.2020 09:47:00
    Даже session-id для cookies не сгенерировали?
     
     
     
    fabian
    Guest
    #15
    0
    23.11.2020 09:55:00
    Для куки не генерируется session-id. PVE использует механизм тикетов на основе подписи для куки, что позволяет всем узлам в кластере проверять тикеты, не требуя синхронизированного состояния для каждого сеанса.
     
     
     
    Joris L.
    Guest
    #16
    0
    23.11.2020 10:07:00
    Спасибо за объяснение. Если я правильно понял, это значит, что подпись действительна после перезапуска сервиса, и новые тикеты выдавать не нужно?
     
     
     
    fabian
    Guest
    #17
    0
    23.11.2020 10:36:00
    Да. Срок действия сессий определяется исключительно временем.
     
     
     
    Joris L.
    Guest
    #18
    0
    23.11.2020 10:40:00
    Теперь-то всё стало понятно. Как администратор, я всё равно буду называть это сессией, хотя она и не основана на session-ID, но использует некую форму идентификатора сессии (билет, верно?). Время-зависимая или нет, главное, чтобы разрешена была связь – сессия существует, хотя здесь она ограничена временным окном, основанным, как я предполагаю, на билете, хранящемся в cookie.
     
     
     
    T.Herrmann
    Guest
    #19
    0
    21.02.2021 16:13:00
    Сохранить решение >>> Войти по SSH на каждом узле и выполнить: service pve-cluster restart && service pvedaemon restart && service pvestatd restart && service pveproxy restart
     
     
     
    mailinglists
    Guest
    #20
    0
    22.02.2021 17:55:00
    systemctl restart pvedaemon и pveproxy должно быть достаточно.
     
     
     
    Страницы: 1
    Читают тему
    +7 (495) 320-70-49
    info@proxmox.su

    Конфиденциальность Оферта
    © 2026 Proxmox.su
    Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры