Bug#615121: #615121: iptables --localtz option of -m time not working
I have marked this as +fixed-upstream, as the --localtz option has been officially deprecated for this very problem; preferably, everything is specified in UTC now. More documentation in iptables-1.4.11's manpage. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#615121: #615121: iptables --localtz option of -m time not working
-=| Jan Engelhardt, Tue, Jun 07, 2011 at 10:40:41PM +0200 |=- I have marked this as +fixed-upstream, as the --localtz option has been officially deprecated for this very problem; preferably, everything is specified in UTC now. More documentation in iptables-1.4.11's manpage. I see. Thanks for the broad and educating explaination. For reference, the commit is https://git.netfilter.org/cgi-bin/gitweb.cgi?p=iptables.git;a=commit;h=db50b83bc3cd634beb71f38978ad7d035c88ff11 I guess I should solve my problem via cron and some date/time calculations. signature.asc Description: Digital signature
Bug#615121: #615121: iptables --localtz option of -m time not working
retitle 615121 iptables --localtz option of -m time not working with hardware clock in UTC thanks -=| Jan Engelhardt, Thu, Mar 31, 2011 at 03:08:40AM +0200 |=- Not sure if it matters, but the hardware clock is using UTC (i.e. /etc/default/rcS contains UTC=yes). When the xt_time kernel module is loaded, it prints the current timezone the kernel is operating with - and this is what xt_time will be using when doing localtz comparisons. Thanks for the reply. Indeed, there is this message in dmesg: xt_time: kernel timezone is - I have set the hardware clock to use the local timezone and it changed to xt_time: kernel timezone is +0300 It seems to fix the problem, but I wonder what would happen at the next DST change. I guess it would require to shut down the firewall, reload xt_time and restart the firewall so that it picks up the correct timezone (If the kernel changes its at all. I have never used UTC=no before). Still a suboptimal solution? signature.asc Description: Digital signature
Bug#615121: #615121: iptables --localtz option of -m time not working
On Thursday 2011-03-31 07:53, Damyan Ivanov wrote: Not sure if it matters, but the hardware clock is using UTC (i.e. /etc/default/rcS contains UTC=yes). When the xt_time kernel module is loaded, it prints the current timezone the kernel is operating with - and this is what xt_time will be using when doing localtz comparisons. Thanks for the reply. Indeed, there is this message in dmesg: xt_time: kernel timezone is - I too use UTC, but I don't get . /etc/sysconfig# head -n10 clock; hwclock; date; rmmod xt_time; modprobe xt_time; dmesg | tail -n1; ## Path:System/Environment/Clock ## Description: Information about your timezone and time ## Type:string(-u,--utc,--localtime) ## ServiceRestart: boot.clock ## Command: /sbin/refresh_initrd # # Set to -u if your system clock is set to UTC, and to --localtime # if your clock runs that way. # HWCLOCK=-u Thu Mar 31 12:16:01 2011 -0.767810 seconds Thu Mar 31 12:16:03 CEST 2011 [383639.470885] xt_time: kernel timezone is +0100 # cat /etc/SuSE-release openSUSE 11.4 (x86_64) I think there is no bug here currently - the Linux system was written such that each user could have his own TZ setting applied to shells, desktop, etc. (Which requires that the kernel always keeps an UTC clock somewhere.) On boot, once the kernel UTC clock has been initialized from the RTC + $(DST result of date command), the KTZ is independent, much like just another user's environment variable. I have set the hardware clock to use the local timezone and it changed to xt_time: kernel timezone is +0300 It seems to fix the problem, but I wonder what would happen at the next DST change. I guess it would require to shut down the firewall, The particular box I have shown output from still reads +0100 while 4 days ago, DST began and thus would have become +0200. Since the KTZ is set by distro scripts once at boot, one can't blame ntpd for not updating the KTZ. After all, ntpd only needs to concern itself with adjusting the UTC clock, since timezones is not a system property, but per-user. Given these findings, the localtz option is obviously heavily dependent on KTZ, and maybe should be ripped out of the xt_time module to avoid surprises. reload xt_time and restart the firewall so that it picks up the correct timezone (If the kernel changes its at all. I have never used UTC=no before). Still a suboptimal solution? Reloading xt_time won't change anything. Someone or something would need to set the KTZ, and once it does so, xt_time will pick it up automatically. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#615121: #615121: iptables --localtz option of -m time not working
Not sure if it matters, but the hardware clock is using UTC (i.e. /etc/default/rcS contains UTC=yes). When the xt_time kernel module is loaded, it prints the current timezone the kernel is operating with - and this is what xt_time will be using when doing localtz comparisons. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
