script to fix qubes-whonix time-sync issue

[qtpie]

The only issue I keep having with Qubes-Whonix, is that after
suspend/resume, Whonix-GW time is out of sync and cant connect to the
Tor network. According to Whonix the safe option is to simply not
suspend Whonix.

https://www.whonix.org/wiki/Post_Install_Advice#Network_Time_Syncing

However with a laptop running from battery not using suspend is not
really an option and manually shutting down multiple qubes is annoying.
To do this automatically I wrote this script, but cant get it working
yet. Any help is welcome.

https://github.com/qtpies/qubes-whonix-suspending

[donoban]

Do you want to restart all domains using sys-whonix netvm? Probably
there are better solutions and I think that Whonix already handles this
properly. I used it for years and I only remember problems with this on
Qubes 3.

Check:
https://github.com/QubesOS/qubes-issues/issues/4989
https://github.com/QubesOS/qubes-issues/issues/4939

[qtpie]

donoban:

My usecase is this: suspend a laptop with sys-whonix and whonix appvms
running, then resume it a few hours later.

After resume Tor lost connection, re-connection fails until i manually
sync time on sys-net then
@sys-firewall 'sudo ntpdate [timeserver]
@sys-whonix 'sudo qvm-sync-clock'
@sys-whonix 'sudo systemctl restart t...@default.service'

Is this also you usecase? You do not expierence any issues after
suspend/resume on qubes 4 with Tor running?

[donoban]

On 9/5/19 11:41 AM, qtpie wrote:> My usecase is this: suspend a laptop

with sys-whonix and whonix appvms
> running, then resume it a few hours later.
>
> After resume Tor lost connection, re-connection fails until i manually
> sync time on sys-net then
> @sys-firewall 'sudo ntpdate [timeserver]
> @sys-whonix 'sudo qvm-sync-clock'
> @sys-whonix 'sudo systemctl restart t...@default.service'
>
> Is this also you usecase? You do not expierence any issues after
> suspend/resume on qubes 4 with Tor running?
>

Ouch yes, usually after suspend/resume I had to run just:

@sys-whonix 'sudo systemctl restart t...@default.service'

Currently I am not using whonix, I am testing with minimal fedora torvm[1].

It seems stable. I don't have problems with suspend/resume and I skipped
the sync clock steps [2]. Probably it's less anonymous than Whonix, but
for me seems fine.

[1] https://hackmd.io/JIXLStC-Sbq8rr1mjomCDQ
[2]
https://hackmd.io/JIXLStC-Sbq8rr1mjomCDQ#Fix-clock-synchronization-issue-after-suspendresume-cycle-in-dom0

[unman]

On Thu, Sep 05, 2019 at 12:23:13PM +0200, donoban wrote:
> On 9/5/19 11:41 AM, qtpie wrote:> My usecase is this: suspend a laptop
> with sys-whonix and whonix appvms
> > running, then resume it a few hours later.
> >
> > After resume Tor lost connection, re-connection fails until i manually
> > sync time on sys-net then
> > @sys-firewall 'sudo ntpdate [timeserver]
> > @sys-whonix 'sudo qvm-sync-clock'
> > @sys-whonix 'sudo systemctl restart t...@default.service'
> >
> > Is this also you usecase? You do not expierence any issues after
> > suspend/resume on qubes 4 with Tor running?
> >
>
> Ouch yes, usually after suspend/resume I had to run just:
> @sys-whonix 'sudo systemctl restart t...@default.service'
>
>
> Currently I am not using whonix, I am testing with minimal fedora torvm[1].
>
> It seems stable. I don't have problems with suspend/resume and I skipped
> the sync clock steps [2]. Probably it's less anonymous than Whonix, but
> for me seems fine.
>
> [1] https://hackmd.io/JIXLStC-Sbq8rr1mjomCDQ

You know there's a Qubes package for that? (deprecated but still
buildable.)
I have my own fork for a torVM which includes Qubes firewall
support, which Whonix doesn't provide.

[qtpie]

unman:

> On Thu, Sep 05, 2019 at 12:23:13PM +0200, donoban wrote:
>> On 9/5/19 11:41 AM, qtpie wrote:> My usecase is this: suspend a laptop
>> with sys-whonix and whonix appvms
>>> running, then resume it a few hours later.
>>>
>>> After resume Tor lost connection, re-connection fails until i manually
>>> sync time on sys-net then
>>> @sys-firewall 'sudo ntpdate [timeserver]
>>> @sys-whonix 'sudo qvm-sync-clock'

>>> @sys-whonix 'sudo systemctl restart tor-fCAy/Bagh0FXz...@public.gmane.org'

>>>
>>> Is this also you usecase? You do not expierence any issues after
>>> suspend/resume on qubes 4 with Tor running?
>>>
>>
>> Ouch yes, usually after suspend/resume I had to run just:

>> @sys-whonix 'sudo systemctl restart tor-fCAy/Bagh0FXz...@public.gmane.org'

>>
>>
>> Currently I am not using whonix, I am testing with minimal fedora torvm[1].
>>
>> It seems stable. I don't have problems with suspend/resume and I skipped
>> the sync clock steps [2]. Probably it's less anonymous than Whonix, but
>> for me seems fine.
>>
>> [1] https://hackmd.io/JIXLStC-Sbq8rr1mjomCDQ
>
> You know there's a Qubes package for that? (deprecated but still
> buildable.)
> I have my own fork for a torVM which includes Qubes firewall
> support, which Whonix doesn't provide.
>

Which package? I couldnt immediately find it.

[qtpie]

qtpie:

> unman:
>> On Thu, Sep 05, 2019 at 12:23:13PM +0200, donoban wrote:
>>> On 9/5/19 11:41 AM, qtpie wrote:> My usecase is this: suspend a laptop
>>> with sys-whonix and whonix appvms
>>>> running, then resume it a few hours later.
>>>>
>>>> After resume Tor lost connection, re-connection fails until i manually
>>>> sync time on sys-net then
>>>> @sys-firewall 'sudo ntpdate [timeserver]
>>>> @sys-whonix 'sudo qvm-sync-clock'

>>>> @sys-whonix 'sudo systemctl restart tor-fCAy/Bagh0FXz5zEmyOJwQ-XM...@public.gmane.org'

>>>>
>>>> Is this also you usecase? You do not expierence any issues after
>>>> suspend/resume on qubes 4 with Tor running?
>>>>
>>>
>>> Ouch yes, usually after suspend/resume I had to run just:

>>> @sys-whonix 'sudo systemctl restart tor-fCAy/Bagh0FXz5zEmyOJwQ-XM...@public.gmane.org'

>>>
>>>
>>> Currently I am not using whonix, I am testing with minimal fedora torvm[1].
>>>
>>> It seems stable. I don't have problems with suspend/resume and I skipped
>>> the sync clock steps [2]. Probably it's less anonymous than Whonix, but
>>> for me seems fine.
>>>
>>> [1] https://hackmd.io/JIXLStC-Sbq8rr1mjomCDQ
>>
>> You know there's a Qubes package for that? (deprecated but still
>> buildable.)
>> I have my own fork for a torVM which includes Qubes firewall
>> support, which Whonix doesn't provide.
>>
>
> Which package? I couldnt immediately find it.
>

FYI: I'm also going to apply shutdown-on-suspend to sys-usb, since I
have to kill it manually right now since it hangs after resume. It might
not be elegant, there might be a bug/fix, but I dont care, just want the
problem solved.

If anyone knows the existing package to do this it would be very welcome.

[qtpie]

[rec wins]

On 9/6/19 4:55 AM, qtpie wrote:
> qtpie:
>> unman:
>>> On Thu, Sep 05, 2019 at 12:23:13PM +0200, donoban wrote:
>>>> On 9/5/19 11:41 AM, qtpie wrote:> My usecase is this: suspend a laptop
>>>> with sys-whonix and whonix appvms
>>>>> running, then resume it a few hours later.
>>>>>
>>>>> After resume Tor lost connection, re-connection fails until i manually
>>>>> sync time on sys-net then
>>>>> @sys-firewall 'sudo ntpdate [timeserver]
>>>>> @sys-whonix 'sudo qvm-sync-clock'

>>>>> @sys-whonix 'sudo systemctl restart tor-fCAy/Bagh0FXz5zEmyOJwQ-XMD5yJDbdMReX...@public.gmane.org'

>>>>>
>>>>> Is this also you usecase? You do not expierence any issues after
>>>>> suspend/resume on qubes 4 with Tor running?
>>>>>
>>>>
>>>> Ouch yes, usually after suspend/resume I had to run just:

>>>> @sys-whonix 'sudo systemctl restart tor-fCAy/Bagh0FXz5zEmyOJwQ-XMD5yJDbdMReX...@public.gmane.org'

>>>>
>>>>
>>>> Currently I am not using whonix, I am testing with minimal fedora torvm[1].
>>>>
>>>> It seems stable. I don't have problems with suspend/resume and I skipped
>>>> the sync clock steps [2]. Probably it's less anonymous than Whonix, but
>>>> for me seems fine.
>>>>
>>>> [1] https://hackmd.io/JIXLStC-Sbq8rr1mjomCDQ
>>>
>>> You know there's a Qubes package for that? (deprecated but still
>>> buildable.)
>>> I have my own fork for a torVM which includes Qubes firewall
>>> support, which Whonix doesn't provide.
>>>
>>
>> Which package? I couldnt immediately find it.
>>
>
> FYI: I'm also going to apply shutdown-on-suspend to sys-usb, since I
> have to kill it manually right now since it hangs after resume. It might
> not be elegant, there might be a bug/fix, but I dont care, just want the
> problem solved.
>
> If anyone knows the existing package to do this it would be very welcome.
>

I have been running sdwtime-gui in sys-whonix and anon-whonix every
time I use them, then it is hit and miss whether it awakes and has
failed, but I don't suspend so often