Skip to content
This repository has been archived by the owner on Jan 15, 2019. It is now read-only.

[dev.icinga.com #2485] run command proposed time is client, not server #737

Closed
icinga-migration opened this issue Mar 30, 2012 · 14 comments
Closed
Assignees

Comments

@icinga-migration
Copy link

This issue has been migrated from Redmine: https://dev.icinga.com/issues/2485

Created by mephisto23 on 2012-03-30 11:42:26 +00:00

Assignee: mhein
Status: Assigned
Target Version: Backlog
Last Update: 2015-05-18 12:17:32 +00:00 (in Redmine)

Icinga Version: 1.6.1
Icinga Web Version: 1.6.1
IDO Version: 1.6.1
OS Version: Debian
DB Type: MySQL
DB Version: 5.5
Browser Version: chromium 21

when i run a command like "disable notification" and give a force time, the proposed time is always the local time and not the servertime. thats ok but it is also saved in local time and thats a problem, cause the sync to my time horizon is away. the same in downtime part. (ICINGA-WEB)


Relations:

@icinga-migration
Copy link
Author

Updated by jmosshammer on 2012-04-13 09:43:42 +00:00

So your server is in another timezone than you are?

@icinga-migration
Copy link
Author

Updated by mephisto23 on 2012-04-13 09:57:54 +00:00

all our server are utc, our clients are german time. of course these zones differ and it is usual like that. thats at least my experience with large companie infrastructures. we cooperate with a lot of them spread over the world and they are all using utc for the servers and local time zones for the clients.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2012-04-13 10:01:12 +00:00

this issue lacks of any version information. can you clarify on the icinga* versions used, as well as the database backend?

@icinga-migration
Copy link
Author

Updated by mephisto23 on 2012-04-13 10:04:32 +00:00

icinga-web 1.6.2, icinga debian 1.6.1, mysql backend initially created with an early 1. version and upgraded since then.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2012-04-13 10:05:46 +00:00

mysql> select * from icinga_dbversion;

@icinga-migration
Copy link
Author

Updated by mephisto23 on 2012-04-13 10:08:59 +00:00

mysql> select * from icinga_dbversion;

-------------~~------------------~~
| dbversion_id | name | version |

-------------~~------------------~~
| 1 | idoutils | 1.4.0 |

-------------~~------------------~~
1 row in set (0.00 sec)

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2012-04-13 10:11:59 +00:00

@Jannis

one beer for me :D

@MEPHISTO23
db schema upgrade is missing 2 incremental steps (1.5 and 1.6).

debian installs the manual sqls here

/usr/share/doc/icinga-idoutils/examples/mysql/upgrade/

import those manually as described in the upgrade docs for idoutils.

@icinga-migration
Copy link
Author

Updated by mephisto23 on 2012-04-13 10:31:38 +00:00

done, but the "issue" is still there. servertime = utc, my pcs time = german time. when i add a downtime for 12.00 the downtime should be saved with value 10.00 but that does not happen.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2012-04-13 10:38:00 +00:00

mephisto23 wrote:

done

again the query output. and maybe some examples (screenshots) to examine your problem a bit more.

@icinga-migration
Copy link
Author

Updated by mephisto23 on 2012-04-17 12:18:29 +00:00

mysql> select * from icinga_dbversion;

-------------~~------------------~~
| dbversion_id | name | version |

-------------~~------------------~~
| 1 | idoutils | 1.6.0 |

-------------~~------------------~~
1 row in set (0.00 sec)

@icinga-migration
Copy link
Author

Updated by mephisto23 on 2012-04-17 12:22:53 +00:00

to reproduce this issue you need a server with utc and a client with a time different to utc. if you then schedule something in icinga-web, you will see that icinga-web offers you ythe client time and save that client time also to the server, but the server is working in utc and will do the job in utc. if i say, i have a downtime for a host at 3pm time of my client, the server will do that at 3pm utc, which can differ up to hours. hope the problem is clear now.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2012-09-06 21:38:27 +00:00

  • Subject changed from time issues to run command proposed time is client, not server
  • Icinga Version set to 1
  • Icinga Web Version set to 1
  • IDO Version set to 1
  • OS Version set to Debian
  • DB Type set to MySQL
  • DB Version set to 5
  • Browser Version set to chromium 21

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2013-04-08 20:25:09 +00:00

  • Status changed from New to Assigned
  • Assigned to set to mhein

@icinga-migration
Copy link
Author

Updated by berk on 2015-05-18 12:17:32 +00:00

  • Target Version set to Backlog

@icinga-migration icinga-migration added this to the Backlog milestone Jan 17, 2017
@dnsmichi dnsmichi removed this from the Backlog milestone Dec 19, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants