summaryrefslogtreecommitdiffstats
path: root/zarb-ml/mageia-sysadm/2011-July/003752.html
blob: 5f94e047a8134e07db8b9ec70729ec6cf229630b (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
 <HEAD>
   <TITLE> [Mageia-sysadm] Questions about puppet config
   </TITLE>
   <LINK REL="Index" HREF="index.html" >
   <LINK REL="made" HREF="mailto:mageia-sysadm%40mageia.org?Subject=Re%3A%20%5BMageia-sysadm%5D%20Questions%20about%20puppet%20config&In-Reply-To=%3C1410745291.775371311036840736.JavaMail.root%40spooler6-g27.priv.proxad.net%3E">
   <META NAME="robots" CONTENT="index,nofollow">
   <META http-equiv="Content-Type" content="text/html; charset=us-ascii">
   <LINK REL="Previous"  HREF="003814.html">
   <LINK REL="Next"  HREF="003760.html">
 </HEAD>
 <BODY BGCOLOR="#ffffff">
   <H1>[Mageia-sysadm] Questions about puppet config</H1>
    <B>sebelee at free.fr</B> 
    <A HREF="mailto:mageia-sysadm%40mageia.org?Subject=Re%3A%20%5BMageia-sysadm%5D%20Questions%20about%20puppet%20config&In-Reply-To=%3C1410745291.775371311036840736.JavaMail.root%40spooler6-g27.priv.proxad.net%3E"
       TITLE="[Mageia-sysadm] Questions about puppet config">sebelee at free.fr
       </A><BR>
    <I>Tue Jul 19 02:54:00 CEST 2011</I>
    <P><UL>
        <LI>Previous message: <A HREF="003814.html">[Mageia-sysadm] Puppet lockup, potential solution
</A></li>
        <LI>Next message: <A HREF="003760.html">[Mageia-sysadm] Questions about puppet config
</A></li>
         <LI> <B>Messages sorted by:</B> 
              <a href="date.html#3752">[ date ]</a>
              <a href="thread.html#3752">[ thread ]</a>
              <a href="subject.html#3752">[ subject ]</a>
              <a href="author.html#3752">[ author ]</a>
         </LI>
       </UL>
    <HR>  
<!--beginarticle-->
<PRE>After regarding a little bit the puppet configuration, I have some questions about the current puppet configuration.


1) Why using both subscribe() and notify() metaparameters ?

If i'm not mistaken a &quot;file resource&quot; notify a &quot;service&quot;, or a &quot;service&quot; subscribe to a &quot;file ressource&quot; : the result are already the same.
As you say puppet is a little bit too intimidating and in order to be more easy, can we perhaps use only one method ?

For example change all subscribe() calling ?

-----------------------------
modules/ntp/manifests/init.pp
-----------------------------
class ntp {

    package { ntp: 
        ensure =&gt; installed
    }

    service { ntpd:
        ensure =&gt; running,
        path =&gt; &quot;/etc/init.d/ntpd&quot;,
    }
    
    file { &quot;ntp.conf&quot;:
        path =&gt; &quot;/etc/ntp.conf&quot;,
        ensure =&gt; present,
        owner =&gt; root,
        group =&gt; root,
        mode =&gt; 644,
        require =&gt; Package[&quot;ntp&quot;],
        content =&gt; template(&quot;ntp/ntp.conf&quot;),
	notify =&gt; Service[&quot;ntpd&quot;],
    }
}


 
2) In the same idea, after reading the beginning of the book &quot;Pro Puppet&quot;, the author describes a sort of Best Pratice for managing puppet's module.

The book extract :
&lt;&lt; In Listing 2-2, we created a functional structure by dividing the components of the service we're managing into functional domains: things to be installed, things to be configured and things to be executed or run. &gt;&gt;

He also split a module in 3 files and include all of them into init.pp
- manifests/install.pp  
- manifests/config.pp   
- manifests/service.pp 


For example with the ntp service : 

--------------------------------
modules/ntp/manifests/install.pp
--------------------------------
class ntp::install {
    package { &quot;ntp&quot;: 
        ensure =&gt; installed
    }
}

--------------------------------
modules/ntp/manifests/config.pp
--------------------------------
class ntp::config {
    file { &quot;ntp.conf&quot;:
        path =&gt; &quot;/etc/ntp.conf&quot;,
        ensure =&gt; present,
        owner =&gt; root,
        group =&gt; root,
        mode =&gt; 644,
        content =&gt; template(&quot;ntp/ntp.conf&quot;),
        require =&gt; Class[&quot;ntp::install&quot;],
 	notify =&gt; Class[&quot;ntp::service&quot;],
    }
}

--------------------------------
modules/ntp/manifests/service.pp
--------------------------------
class ntp::service {
    service { &quot;ntpd&quot;:
        ensure =&gt; running,
        path =&gt; &quot;/etc/init.d/ntpd&quot;,
    }
}

-----------------------------
modules/ntp/manifests/init.pp
-----------------------------
class ntp {
    include ntp::install, ntp::config, ntp::service
}


Also we have the same logical, a &quot;config ressource&quot;
- need a &quot;install ressource&quot; (packages) 
- and notify a &quot;service&quot;



3) With this schema, we can also classify specials functionnalites or class by creating one or more extra file(s) 

  a) for example for the &quot;define vhost_redirect_ssl&quot; in apache module
 
   ----------------------------------
   modules/apache/manifests/vhosts.pp
   ----------------------------------
   ...
    define apache::vhost_redirect_ssl() {
        vhost_base { &quot;redirect_ssl_$name&quot;:
            vhost =&gt; $name,
            content =&gt; template(&quot;apache/vhost_ssl_redirect.conf&quot;)
        }
    }
    ...



   b) or for make differences between tasks, example for cronjobs

   ------------------------------------
   deployement/common/manifests/cron.pp
   ------------------------------------
   class common::urpmi_update {
      cron { urpmi_update:
             user =&gt; root,
             hour =&gt; '*/4',
             minute =&gt; 0,
             command =&gt; &quot;/usr/sbin/urpmi.update -a -q&quot;,
      }
   }



I'm just a beginner with puppet and I don't know if this a method can work for a production environnement day after day...
But i think instead of having all the module's classes in a same file, split them into specifics items would be more easy for understanding and also give more granularity.


What do you thing about this approach ?

--
S&#233;bastien Kurtzemann
</PRE>




















<!--endarticle-->
    <HR>
    <P><UL>
        <!--threads-->
	<LI>Previous message: <A HREF="003814.html">[Mageia-sysadm] Puppet lockup, potential solution
</A></li>
	<LI>Next message: <A HREF="003760.html">[Mageia-sysadm] Questions about puppet config
</A></li>
         <LI> <B>Messages sorted by:</B> 
              <a href="date.html#3752">[ date ]</a>
              <a href="thread.html#3752">[ thread ]</a>
              <a href="subject.html#3752">[ subject ]</a>
              <a href="author.html#3752">[ author ]</a>
         </LI>
       </UL>

<hr>
<a href="https://www.mageia.org/mailman/listinfo/mageia-sysadm">More information about the Mageia-sysadm
mailing list</a><br>
</body></html>