[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-relays] Relay's clock settings off no matter what
You'd think, but not always. Relying on an openvz hypervisor to be
"not fucked up" is a gamble.
I, for example, routinely run into openvz hosts that don't have the
most *basic* iptables modules loaded in the kernel for connection
tracking (read: stateful firewall).
I have to seriously have specific checks in my puppet manifests to
make sure I'm not running on openvz, otherwise fierwalls will fail
more often than not.
On Fri, Nov 14, 2014 at 5:10 AM, s7r <s7r@xxxxxxxxxx> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Or FreeBSD Jail system... anyway your provider has the interest to
> have an accurate time on the host server... so it shouldn't be a
> problem at all - it can be fixed in few seconds.. it's just a
> misconfiguration.
>
> No sane person will refuse to set the correct time on a host server...
>
> On 11/14/2014 12:49 PM, eric gisse wrote:
>> If your vps provider is openvz, you are shit out of luck because
>> you can't set time.
>>
>> On Fri, Nov 14, 2014 at 4:37 AM, s7r <s7r@xxxxxxxxxx> wrote: Hello
>> Austin,
>>
>> The clock is very important to Tor, you need accurate clock all the
>> time.
>>
>> Do you run NTPDATE or NTPD service inside your VPS? The virutal
>> servers are sometimes problematic, depending on virtualization,
>> when coming to hwclock and dedicated time.
>>
>> You need to open a ticket with your VPS provider and ask them what
>> virtualization technique they use and if there is a NTP daemon on
>> the hypervisor (physical host server) which sets the time inside
>> the guests (virtual machines). Make sure the time is correct on
>> your master host server and rely on that time instead of trying to
>> run your own NTP service. If they say the master server doesn't run
>> this service or set the time inside guests (i doubt it), you can
>> then run NTP inside your VPS as follows:
>>
>> (NTP and NTPDATE are included in FreeBSD base system so you don't
>> have to install anything). Run these commands:
>>
>> $ service ntpd stop (or onestop if stop doesn't work, if it says
>> ntpd is not running just proceed with the following commands)
>>
>> $ echo 'ntp_enable="YES"' >> /etc/rc.conf $ echo
>> 'ntpdate_enable="YES"' >> /etc/rc.conf $ ntpdate
>> 0.rhel.pool.ntp.org $ service ntpd start
>>
>> Your timezone does not matter. Tor calculates the time in UNIX
>> time format, so you can be in any time zone, GMT +1, UTC, EET,
>> whatever - Tor will work just fine if the UNIX time format is
>> accurate. The localtime via timezone is just a
>> translation/calculation of UNIX timestamp.
>>
>> On 11/14/2014 6:59 AM, Austin Bentley wrote:
>>>>> Hello everyone,
>>>>>
>>>>> I have an interesting problem. I am monitoring my relay using
>>>>> arm. I am getting the following warnings:
>>>>>
>>>>>> 05:56:12 [WARN] Received directory with skewed time
>>>>>> (server
>>>>> '154.35.32.5:80'): It seems that our clock is behind by 1
>>>>> hours, 0 minutes, or that theirs is ahead. Tor requires an
>>>>> accurate clock to work: please check your time, timezone, and
>>>>> date settings.
>>>>>
>>>>> Most of the messages tell me that my clock is an hour
>>>>> behind. However, I also get these messages occasionally (but
>>>>> not as often):
>>>>>> 02:07:27 [WARN] Our clock is 52 minutes, 35 seconds behind
>>>>>> the time
>>>>> published in the consensus network status document
>>>>> (2014-11-14 02:00:00 UTC). Tor needs an accurate clock to
>>>>> work correctly. Please check your time and date settings!
>>>>>
>>>>>
>>>>> I am running a Tor exit relay on a FreeBSD VPS. Said VPS is
>>>>> in Czech Republic. If I set the time to CET, it is 1 hour
>>>>> behind true CET (GMT+1); therefore, I have it set to EET
>>>>> (GMT+2.) I have verified the time is correct in Czech
>>>>> Republic. This problem is rather frustrating because it is
>>>>> causing my server to throw away circuit data as old data.
>>>>>
>>>>> Could someone shine some light on this?
>>>>>
>>>>> Thanks, Austin
>>>>>
>>>>>
>>>>> _______________________________________________ tor-relays
>>>>> mailing list tor-relays@xxxxxxxxxxxxxxxxxxxx
>>>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>>>>
>>>
>>>>>
> _______________________________________________
>>> tor-relays mailing list tor-relays@xxxxxxxxxxxxxxxxxxxx
>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>> _______________________________________________ tor-relays mailing
>> list tor-relays@xxxxxxxxxxxxxxxxxxxx
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (MingW32)
>
> iQEcBAEBAgAGBQJUZeM8AAoJEIN/pSyBJlsRGeEH/2ElP4+Z7uD2PQkYk25tq7ji
> VVTUwxa5qweD4/YBWwoohhMmii+yY4ZoLnmoevNh2Y3PxTwC49N5nyQH7CQL59OU
> gIL8GCfmoJD6mjv+cCENn+g/iPUpb5eIhuKnLnh0dm49pj5t0Wb8H3R6HUR+BGnA
> Me3SOwfWT3XR6Ktd93Ev/yY03vRRFFhSQShGCeSwKIIT6CvKWgTSXCi4SZsslY5B
> mvRJMx99dYbEFuL32hNkPtcx5mr7JkUQamWJzuzPEY4HDFaYIW0zU0SBcFBbXVjT
> MClytBVcS1YznSMC/l9eusnijDO4LCM7We6EsjRmWWgPKOg+SsoMbCtZzmh+Y0k=
> =piNO
> -----END PGP SIGNATURE-----
> _______________________________________________
> tor-relays mailing list
> tor-relays@xxxxxxxxxxxxxxxxxxxx
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
_______________________________________________
tor-relays mailing list
tor-relays@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays