🚀 go-pugleaf

Dnia 18.02.2023 Andrzej A. Filip <anfi@onet.eu> napisał/a:

> Moje obecnie podejście to dwa połączenia w Network Manager różniące się
> tym że jedno ma odhaczone "metered connection" a drugie nie
> praz "ręczne" przełączanie między nimi".

Nie jest to zapewne bardzo eleganckie, ale ja pomyślałem o skrypcie
który sobie działa w tle i gdy nadejdzie stosowna pora
wykonuje: 
nmcli connection modify POLACZENIE connection.metered yes
(albo 'no', w zależności od pory dnia).

-- 
Dominik Ałaszewski (via raspbianowy slrn)
"W życiu piękne są tylko chwile…" (Ryszard Riedel)
Wyrażam wyłącznie prywatne poglądy zgodnie z Art. 54 Konstytucji RP 
Pisząc na priv zmień domenę na gmail.

Dominik Ałaszewski <Dominik.Alaszewski@gazeta.pl.invalid> pisze:
> Dnia 18.02.2023 Andrzej A. Filip <anfi@onet.eu> napisał/a:
>
>> Moje obecnie podejście to dwa połączenia w Network Manager różniące się
>> tym że jedno ma odhaczone "metered connection" a drugie nie
>> praz "ręczne" przełączanie między nimi".
>
> Nie jest to zapewne bardzo eleganckie, ale ja pomyślałem o skrypcie
> który sobie działa w tle i gdy nadejdzie stosowna pora
> wykonuje: 
> nmcli connection modify POLACZENIE connection.metered yes
> (albo 'no', w zależności od pory dnia).

HGw czy każdy inny program sprawdza za każdym razem czy dane połączenie
jest "metered" czy tylko na starcie albo co się pozmienia w kolejnych
wersjach network managera.

AFAIR Próbowałem czegoś podobnego z wyłączaniem i włączaniem połączeń
ale nmcli *odpalony z cron-a* próbujący wyłączyć połączenie krzyczy:
Connection 'X' deactivation failed: Not authorized to deactivate connections

Krzyczy dla usera który który robi to bez problemów z terminala
(w środowiskach tekstowym i graficznym)

-- 
Andrzej A. Filip

Dnia 19.02.2023 Andrzej A. Filip <anfi@onet.eu> napisał/a:

> HGw czy każdy inny program sprawdza za każdym razem czy dane połączenie
> jest "metered" czy tylko na starcie albo co się pozmienia w kolejnych
> wersjach network managera.

Cóż, nie wiedząc co to za program można gdybać. Debianowy unattended-upgrades
sprawdza przy danym uruchomieniu, a jak nie może sprawdzić, to pisze do loga:

2023-02-19 06:54:54,322 INFO Checking if connection is metered is skipped. 
Please install python3-gi package to detect metered connections 
and skip downloading updates.
[to jest akurat z VPSa na stałym łączu, więc bez znaczenia].

Można też po prostu ograniczyć autoupgrade do krytycznych łat bezpieczeństwa,
a upgrade puszczać ręcznie w stosownych godzinach.

> Krzyczy dla usera który który robi to bez problemów z terminala
> (w środowiskach tekstowym i graficznym)

Widać jakiś mechanizm uwierzytelniania wtedy działa, który z kolei 
nie działa przy odpalaniu z crona. Można w ogóle dać to na osobnym
userze z uprawnieniem w sudoersach tylko do tych konkretnych komend.

Ale typowy cron nie stwierdzi, że poprzedni czas wywołania minął
(np. włączono komputer o 22:30, a o 22:00 powinno się przełączyć).
Może lepiej byłoby użyć timera systemd z parametrem Persistent=true?
Co prawda jeśliby użyć dwóch (włącz/wyłącz), to nie wiem, jak by było gdyby 
minął czas odpalenia dla obu, np. o 6:00 przełącza na metered, o 22:00
na nonmetered. Komputer wyłączono o 22:30, włączono o 22:40 następnego
dnia. Odpalą się oba timery, ale w jakiej kolejności? :-)

Ja chyba bym użył jednego timera z oboma czasami, a sprawdzał czas
wewnątrz wywoływanego serwisu i stosownie przełączał połączenie.

-- 
Dominik Ałaszewski (via raspbianowy slrn)
"W życiu piękne są tylko chwile…" (Ryszard Riedel)
Wyrażam wyłącznie prywatne poglądy zgodnie z Art. 54 Konstytucji RP 
Pisząc na priv zmień domenę na gmail.