PDA

View Full Version : Fedora 18 Time config can't save



easyboot
14th October 2012, 01:20 PM
Fedora 18 Time config can't save.When the coumpter reboot,the time change.

Finalzone
15th October 2012, 07:44 AM
It is a known bug caused by system-config-date (https://bugzilla.redhat.com/show_bug.cgi?id=863676) which needs a fix.

yoshimitsuspeed
27th November 2012, 08:57 PM
Is there any fix to this yet? I looked through those bug reports and I have no localtime file or folder in etc.
I installed the alpha a few days ago and have all updates current.

I was just going to check out FC18 but it has been running well enough to stick with for now. The fact that I can't change my time manually or set the proper local time is about the most annoying thing I have encountered so far.

DBelton
27th November 2012, 09:24 PM
You use timedatectl to set your time, timezone, date, etc... should be run as root user.


timedatectl set-time [time] <--- time is format YYYY-MM-DD HH:MM:SS

timedatectl set-timezone [timezone]
timedatectl list-timezones <-- lists the valid timezones to use in above command

timedatectl set-local-rtc 0 <--- sets UTC
timedatectl set-local-rtc 1 <--- sets local

timedatectl ntp <--- sets it to use network time

timedatectl status <--- shows current settings


Also, system-config-date has been fixed for awhile now, so it should work properly for you as well.

yoshimitsuspeed
27th November 2012, 11:11 PM
Thanks for the input. Something is obviously not right with mine.

# timedatectl status
Local time: Tue, 2012-11-27 21:39:42 UTC
Universal time: Tue, 2012-11-27 21:39:42 UTC
RTC time: Tue, 2012-11-27 21:39:42
Timezone: n/a
NTP enabled: yes
NTP synchronized: yes
RTC in local TZ: yes

Warning: The RTC is configured to maintain time in the local time zone. This
mode is not fully supported and will create various problems with time
zone changes and daylight saving adjustments. If at all possible use
RTC in UTC, by calling 'timedatectl set-local-rtc 0'.

# timedatectl set-timezone America/Denver
# timedatectl set-local-rtc 1

# timedatectl status
Local time: Tue, 2012-11-27 14:45:12 MST
Universal time: Tue, 2012-11-27 21:45:12 UTC
RTC time: Tue, 2012-11-27 14:45:12
Timezone: America/Denver
NTP enabled: yes
NTP synchronized: yes
RTC in local TZ: yes

Warning: The RTC is configured to maintain time in the local time zone. This
mode is not fully supported and will create various problems with time
zone changes and daylight saving adjustments. If at all possible use
RTC in UTC, by calling 'timedatectl set-local-rtc 0'.


With the results above my clock still displays 9:46 PM.


timedatectl set-local-rtc 0 gets rid of the warning above but clock still displays the same time.


# timedatectl ntp
Unknown operation ntp


In the date config GUI if I try to change time zone to Denver it says unable to contact time server
If I try to change the time server it says the same thing.

I also get a selinux warning but still nothing changes even when I put selinux in permissive mode.



SELinux is preventing /usr/libexec/kde4/kcmdatetimehelper from setattr access on the file localtime.

***** Plugin catchall_labels (83.8 confidence) suggests ********************

If you want to allow kcmdatetimehelper to have setattr access on the localtime file
Then you need to change the label on localtime
Do
# semanage fcontext -a -t FILE_TYPE 'localtime'
where FILE_TYPE is one of the following: locale_t, config_usr_t, systemd_passwd_var_run_t.
Then execute:
restorecon -v 'localtime'


***** Plugin catchall (17.1 confidence) suggests ***************************

If you believe that kcmdatetimehelper should be allowed setattr access on the localtime file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep kcmdatetimehelp /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context system_u:system_r:gnomeclock_t:s0-s0:c0.c1023
Target Context system_u:object_r:etc_t:s0
Target Objects localtime [ file ]
Source kcmdatetimehelp
Source Path /usr/libexec/kde4/kcmdatetimehelper
Port <Unknown>
Host localhost.localdomain
Source RPM Packages kde-workspace-4.9.3-2.fc18.x86_64
Target RPM Packages
Policy RPM selinux-policy-3.11.1-50.fc18.noarch
Selinux Enabled True
Policy Type targeted
Enforcing Mode Permissive
Host Name localhost.localdomain
Platform Linux localhost.localdomain 3.6.7-5.fc18.x86_64 #1
SMP Tue Nov 20 19:40:08 UTC 2012 x86_64 x86_64
Alert Count 2
First Seen 2012-11-27 15:02:07 MST
Last Seen 2012-11-27 15:04:10 MST
Local ID 1dc2ae53-e8e6-441f-890f-0c6a466220c6

Raw Audit Messages
type=AVC msg=audit(1354053850.761:319): avc: denied { setattr } for pid=3377 comm="kcmdatetimehelp" name="localtime" dev="sda3" ino=2228914 scontext=system_u:system_r:gnomeclock_t:s0-s0:c0.c1023 tcontext=system_u:object_r:etc_t:s0 tclass=file


type=SYSCALL msg=audit(1354053850.761:319): arch=x86_64 syscall=chmod success=yes exit=0 a0=1f65aa8 a1=1a4 a2=1f65a90 a3=2 items=0 ppid=1 pid=3377 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=kcmdatetimehelp exe=/usr/libexec/kde4/kcmdatetimehelper subj=system_u:system_r:gnomeclock_t:s0-s0:c0.c1023 key=(null)

Hash: kcmdatetimehelp,gnomeclock_t,etc_t,file,setattr

audit2allow
audit2allow -R

Like I said there is also no localtime file in etc so is it somewhere else? Or is SElinux just freaking out at the fact that there isn't a file?

So is this not related to the bug and just an issue on my machine?

AdamW
28th November 2012, 03:19 AM
I believe a file can have an SELinux context even when it does not actually exist, otherwise SELinux would have no way to control whether a given process should or should not be allow to create a given file.

I'm not sure specifically what's going wrong in your case, though.

yoshimitsuspeed
28th November 2012, 03:47 AM
I believe a file can have an SELinux context even when it does not actually exist, otherwise SELinux would have no way to control whether a given process should or should not be allow to create a given file.

I'm not sure specifically what's going wrong in your case, though.

So basically you are saying a program could call on a file or something and selinux could intercept and block it before even confirming the file is actually there? Or something along those lines.
That makes sense.
Well if this is just an odd case of my computer maybe I'll wait a couple updates and see if anything changes. If not I'll just try a new install. I have been kind of planning a fresh install once the final comes out anyway.

AdamW
28th November 2012, 03:51 AM
say Process A wants to create Sensitive File B. We might want to prevent that in SELinux policy. But Sensitive File B doesn't exist yet, obviously! The only way SELinux can control such an operation is if it has the concept of defining properties for a file even before that file exists.

yoshimitsuspeed
29th November 2012, 05:47 PM
Seemed to have fixed it. I stumbled across this thread, http://forums.fedoraforum.org/showthread.php?t=263678 and ran system-config-date as root. This opened up an interface that looked a lot different than the date and time interface in KDE.
I set my local time zone there and then saved. Nothing happened. I did the same thing without being root in the terminal and saved it. Still no change so I decided to reboot. As soon as it restarted date and time seems to be set properly.
I still cannot make changes in the standard time and date settings box. Maybe this is an issue with just KDE or something. I hadn't even thought of that since it sounded like others had this same problem.