1

I've encouter some problems with my module Timezone in Puppet.

So to make it short and clear, I'm in an internship and my boss gave me an assignement : Fix the automated creation of a VM.

The creation use .yaml file with details about the VM inside (CPU,RAM,IP,Backup etc ...) then a html page is make with a makefile with the details of the VM and the xenconf (the cfg file) too.

When a VM is created there is a script that install some packages (whose puppet).

Now I've some problems :

The VM don't have the good time, they're all in UTC and we want them with the localtime of Paris (Europe). First I tried to distribute directly the file but that wasn't working after some research, I tried to use link but the link is not correct, I've a symlink to UTC instead of Europe/Paris. There is my init.pp file for my timezone class :

#
# config de ntpd
#
# $Id: init.pp 5149 2015-07-01 16:11:29Z k***.a**** $
#
# Configuration de la timezone

class timezone {

    # Fichier de configuration
    file { 'timezone':
        path => '/etc/timezone',
        ensure => file,
        source => 'puppet:///modules/timezone/timezone',
    }

   ## Fichier de configuration
   # file { 'localtime':
   #   path => '/etc/localtime',
   #   ensure => file,
   #   source => 'puppet:///modules/timezone/Europe/Paris',
   # }

    file { '/etc/localtime':
    require => Package["tzdata"],
    ensure => link,
    force  => yes,
    target => '/usr/share/zoneinfo/Europe/Paris',
}

    exec { 'update_date':
        command => 'dpkg-reconfigure -f noninteractive tzdata',
        path    => '/usr/local/bin/:/bin/',
        #refreshonly => true,
    }

}

There is some commands I tried, to check my symlink :

ls -F  : localtime@

root@testcreationvm:/etc# file localtime 
localtime: symbolic link to /usr/share/zoneinfo/Etc/UTC

I've one more issue with this module, it's how I can exec the command above (dpkg-reconfigure -f noninteractive tzdata), one time at the creation and after that each time the file or link is modified.

Thx by advance :)

PS : All the VM are Debians (from 7 to 9).

Ghrew
  • 11
  • 2
  • 1
    Instead of reinventing the wheel, try using a common forge module such as https://forge.puppet.com/saz/timezone instead which probably has the benefit of a lot more Debian users using it. – bodgit Feb 26 '19 at 19:15
  • I would love to use a module already done but I can't, my tutor doesn't want to use something done by someone else, at least for "easy" things, that's its words. – Ghrew Feb 27 '19 at 08:29

2 Answers2

2

The Forge and its contributors (of which I am one) have already a lot of hard work into creating the modules for the community, so that people like yourself and your "tutor" do not have to. Using modules is one of the main strengths of using Puppet (or any automation tool). I myself learned long ago to harness the power of the Forge instead of writing my own Puppet codebase.

Forge modules are (by and large) tested and verified to work. Your code will take a fair while to write, will not (I'd imagine) be tested as well as a Forge module and therefore will not (I'd imagine) be as trustworthy as a Forge module. That isn't to say that the code you (or others internally) write will not be good code and work as intended, but "standing on the shoulders of giants" should allow you to spend your time more efficiently doing the work that you should be doing as a systems engineer or developer, rather than menial configuration tasks.

Your manager should value your time, and if you would like to learn Puppet, you can always check out some Forge modules on GitHub to see how they work, or take a stab at fixing some bugs and submitting Pull Requests to the maintainers.

In that vein, the correct solution is to use a Forge module such as saz/timezone.

After installing the module, it's as simple as assigning the class to the node and adding this configuration in Hiera and letting the module take care of the rest. You have no need at all to look into the module's code.

For example:

---
classes:
  - timezone

timezone::timezone: 'Europe/Paris'

Please feel free to point your manager to this answer if he has any queries.

Craig Watson
  • 9,370
  • 3
  • 30
  • 46
  • Do you think I can dowload it and try to merge it with our actual environment ? I looked at the timezone module by saz and it's way more complicate than the module we use, so should I try to merge it with our or replace our by saz one ? If I can do it before the end of the day my tutor will reconsider the use of forge module (I'm stuck on it since monday). – Ghrew Feb 27 '19 at 10:05
  • @Ghrew I would personally replace the internal module with the Forge one, and pass the relatively simple parameters you need via Hiera. – Craig Watson Feb 27 '19 at 15:20
0

I found why it wasn't working, the module timezone wasn't properly declared in the common.yaml, in the hieradata folder, in the production environment.

Here is my common.yaml file (part of):

base:
    - adminkey
    - apt
    - assimilate
    - cacti
    - exim4
    - facteraddon
    - fsck
    - initramfs
    - locales
    - monit
    - motd
    - nagios
    - needrestart
    - ntpd
    - puppet
    - rc
    - resolv
    - root
    - snmpd
    - sshd
    - sudo
    - timezone
    - users

dom0:
    - hostsfile
    - kernels
    - xen_tools
etc ...

And there is my class timezone : 

class timezone {

    # Fichier de configuration
    file { 'timezone':
        path => '/etc/timezone',
        ensure => file,
        source => 'puppet:///modules/timezone/timezone',
    }

    file { '/etc/localtime':
        ensure => link,
        target => '/usr/share/zoneinfo/Europe/Paris',
        force  => yes,
    }
}
Ghrew
  • 11
  • 2