NetSendo
Platform Updates

NetSendo v2.8.7: naprawa aktualizacji na Podmanie i zmiana portu Reverb

NetSendo Team6 min czytania

Self-hosting daje Ci kontrolę nad całym stosem marketingowym: danymi, serwerami i limitami wysyłki. Oznacza też, że musisz polegać na tym, że aktualizacje przechodzą bez problemów. Jeśli uruchamiasz NetSendo na Podmanie, Twoja instalacja najpewniej nie zaktualizowała się od wersji 2.8.0, a system mógł Cię o tym wyraźnie nie poinformować.

NetSendo v2.8.7 to naprawia. To niewielka zmiana w docker-compose.yml, ale ważna, bo dopiero ona pozwala instalacjom na Podmanie otrzymać poprawki bezpieczeństwa z wersji 2.8.5 i 2.8.6.

TL;DR: Od wersji 2.8.0 mapowanie portu Reverb w docker-compose.yml używało zagnieżdżonej wartości domyślnej, której podman-compose nie potrafi przetworzyć. Aktualizacje na Podmanie kończyły się błędem „invalid port format” i były wycofywane do 2.7.x. v2.8.7 zastępuje ją wartością jednopoziomową ${REVERB_HOST_PORT:-8085}. Dla użytkowników Dockera nic się nie zmienia. Jeśli zmieniałeś port hosta Reverb przez REVERB_PORT, użyj teraz REVERB_HOST_PORT.

🚀 Co nowego w v2.8.7

Problem: jedna linia, dwa interpretery

NetSendo uruchamia Reverb, czyli serwer WebSocket obsługujący aktualizacje w czasie rzeczywistym, w osobnym kontenerze. Od wersji 2.8.0 mapowanie jego portu korzystało z zagnieżdżonej wartości domyślnej:

# Przed (2.8.0 – 2.8.6)
${REVERB_HOST_PORT:-${REVERB_PORT:-8085}}

Mówiąc prościej: „użyj REVERB_HOST_PORT; jeśli nie jest ustawiona, użyj REVERB_PORT; jeśli i tej nie ma, użyj 8085”. Docker Compose rozwija to bez problemu. podman-compose nie obsługuje zagnieżdżonych wartości domyślnych, więc przekazywał nierozwinięty tekst jako wartość portu.

To jak plan awaryjny wewnątrz planu awaryjnego. Jeden czytelnik rozumie oba poziomy, drugi zatrzymuje się na pierwszym i dostaje bezsensowny wynik. W efekcie podman-compose up -d zgłaszał błąd „invalid port format”, aktualizacja była wycofywana, a instalacja zostawała na 2.7.x.

⚠️ Ważne: Instalacje na Podmanie, które utknęły na 2.7.x, nie mają poprawek bezpieczeństwa z 2.8.5 i 2.8.6. Jeśli używasz Podmana, potraktuj tę aktualizację priorytetowo.

Rozwiązanie: wartość domyślna jednopoziomowa

# Po zmianie (2.8.7+)
${REVERB_HOST_PORT:-8085}
🦭

Zgodność z Podmanem

podman-compose poprawnie przetwarza linię portu i aktualizacje znowu się kończą.

🐳

Bez zmian na Dockerze

Reverb nadal jest domyślnie publikowany na 0.0.0.0:8085.

⚙️

Te same ustawienia wszędzie

REVERB_HOST_PORT i REVERB_BIND_ADDRESS działają na Dockerze i na Podmanie.

REVERB_PORT a REVERB_HOST_PORT

Te dwie zmienne pełnią różne funkcje, a v2.8.7 wyraźnie je rozdziela:

  • REVERB_HOST_PORT: port, na którym Reverb jest publikowany na hoście. Zmień go, jeśli port 8085 jest zajęty.
  • REVERB_PORT: port, przez który aplikacja łączy się z Reverb wewnątrz sieci kontenerów. Musi pozostać 8085.
ℹ️ Uwaga: Jeśli wcześniej zmieniałeś port hosta Reverb przez REVERB_PORT, ta ścieżka zastępcza już nie istnieje. Ustaw REVERB_HOST_PORT, zgodnie z sekcją Port 8085 Already in Use w pliku DOCKER_INSTALL.md.

💼 Kogo to dotyczy: scenariusze z praktyki

🛒

Sklep internetowy na serwerze z rodziny RHEL

Sklep prowadzi sekwencje porzuconych koszyków i wiadomości po zakupie na serwerze z Fedorą, RHEL lub AlmaLinux, gdzie domyślnym silnikiem kontenerów jest Podman:

  • Od wersji 2.8.0 każda próba aktualizacji była po cichu wycofywana
  • Z v2.8.7 aktualizacja przechodzi i wprowadza poprawki bezpieczeństwa z 2.8.5/2.8.6
  • Dane klientów i kampanie działają dalej bez zmian w konfiguracji
🚀

Zespół SaaS z kontenerami rootless

Firma SaaS ze względów bezpieczeństwa uruchamia e-maile onboardingowe i kampanie przeciw odejściom klientów na Podmanie w trybie rootless:

  • Przeniosła Reverb na inny port hosta przez REVERB_PORT, bo 8085 był zajęty
  • Musi przenieść tę wartość do REVERB_HOST_PORT i przywrócić REVERB_PORT na 8085
  • Funkcje czasu rzeczywistego dalej działają na niestandardowym porcie
🏢

Agencja z wieloma instancjami klientów

Agencja utrzymuje kilka instancji NetSendo na jednej maszynie i każda potrzebuje własnego portu hosta dla Reverb:

  • Każda instancja dostaje unikalny REVERB_HOST_PORT (8085, 8086, 8087…)
  • REVERB_PORT=8085 zostaje wszędzie bez zmian
  • REVERB_BIND_ADDRESS pozwala ograniczyć ekspozycję, np. do localhost za reverse proxy

🛠️ Krok po kroku: przejście na v2.8.7

  1. Sprawdź obecną wersję

    Zobacz, jaką wersję zgłasza Twoja instalacja. Jeśli używasz Podmana i nadal masz 2.7.x, ten błąd dotyczył Ciebie.

  2. Przejrzyj plik .env

    Poszukaj REVERB_PORT. Jeśli ma wartość inną niż 8085, przenieś ją do REVERB_HOST_PORT i przywróć REVERB_PORT na 8085.

    # Przykład: Reverb na porcie hosta 8090
    REVERB_HOST_PORT=8090
    REVERB_PORT=8085
  3. Zrób kopię zapasową

    Jak zwykle zabezpiecz bazę danych i plik .env. To kilka minut, które zawsze się opłacają.

  4. Przeprowadź standardową aktualizację

    Zaktualizuj do v2.8.7 tak jak zwykle. Na Podmanie kontenery powinny teraz wystartować poleceniem:

    podman-compose up -d
  5. Sprawdź publikację Reverb

    Upewnij się, że kontener Reverb działa i jest zmapowany na oczekiwany port hosta:

    podman ps --format "{{.Names}} {{.Ports}}"
    # lub na Dockerze
    docker compose ps

Typowe problemy

  • Funkcje czasu rzeczywistego przestały działać po aktualizacji: REVERB_PORT najpewniej ma wartość inną niż 8085. Przywróć ją i zrestartuj stos.
  • „Port already in use”: inna usługa zajmuje 8085. Ustaw REVERB_HOST_PORT na wolny port.
  • Własne pliki override: jeśli skopiowałeś stare zagnieżdżone wyrażenie do własnego pliku, zamień je na formę jednopoziomową.

🎯 Porady ekspertów

1
Pilnuj cichych wycofań

Automatyczne wycofanie chroni przed zepsutymi aktualizacjami, ale potrafi też ukryć problem. Po każdej aktualizacji sprawdź, czy wersja faktycznie się zmieniła.

2
Oddzielaj porty hosta od wewnętrznych

Zmieniaj to, co widzi świat zewnętrzny (REVERB_HOST_PORT), a nigdy to, czego kontenery używają do komunikacji między sobą (REVERB_PORT).

3
Ogranicz adres nasłuchu

Jeśli Reverb działa za reverse proxy, ustaw REVERB_BIND_ADDRESS na 127.0.0.1, żeby port nie był wystawiony na wszystkich interfejsach.

4
Weryfikuj pliki compose przed wdrożeniem

Uruchom docker compose config lub przetestuj podman-compose na środowisku staging, żeby wychwycić błędy parsowania przed produkcją.

💡 Wskazówka: Obserwuj wydania NetSendo na GitHubie (Watch → Custom → Releases), żeby szybko dowiadywać się o wydaniach z poprawkami bezpieczeństwa.

✅ Podsumowanie

  • ✅ Instalacje na Podmanie znowu mogą się aktualizować po utknięciu na 2.7.x
  • ✅ Dostęp do poprawek bezpieczeństwa z 2.8.5 i 2.8.6
  • ✅ Brak zmian w działaniu instalacji na Dockerze
  • ✅ Jasny podział: REVERB_HOST_PORT dla hosta, REVERB_PORT zawsze 8085

v2.8.7 to małe wydanie, ale jeśli korzystasz z Podmana, to jedna z najważniejszych aktualizacji w tym roku. Zaktualizuj, sprawdź zmienne Reverb i upewnij się, że nowa wersja działa.

Zadbaj o bezpieczeństwo i aktualność NetSendo

Przeczytaj dokumentację instalacji, przejrzyj integracje lub zacznij nową instalację self-hosted:

Poznaj integracje i zostaw ⭐ na GitHubie.

#podman#docker#release#security#reverb#self-hosted
Udostępnij