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
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE> [Mageia-webteam] Webteam peers, bootstrapping
</TITLE>
<LINK REL="Index" HREF="index.html" >
<LINK REL="made" HREF="mailto:mageia-webteam%40mageia.org?Subject=Re%3A%20%5BMageia-webteam%5D%20Webteam%20peers%2C%20bootstrapping&In-Reply-To=%3C1294325052.3329.47.camel%40akroma.ephaone.org%3E">
<META NAME="robots" CONTENT="index,nofollow">
<META http-equiv="Content-Type" content="text/html; charset=us-ascii">
<LINK REL="Previous" HREF="000105.html">
<LINK REL="Next" HREF="000100.html">
</HEAD>
<BODY BGCOLOR="#ffffff">
<H1>[Mageia-webteam] Webteam peers, bootstrapping</H1>
<B>Michael Scherer</B>
<A HREF="mailto:mageia-webteam%40mageia.org?Subject=Re%3A%20%5BMageia-webteam%5D%20Webteam%20peers%2C%20bootstrapping&In-Reply-To=%3C1294325052.3329.47.camel%40akroma.ephaone.org%3E"
TITLE="[Mageia-webteam] Webteam peers, bootstrapping">misc at zarb.org
</A><BR>
<I>Thu Jan 6 15:44:12 CET 2011</I>
<P><UL>
<LI>Previous message: <A HREF="000105.html">[Mageia-webteam] Webteam peers, bootstrapping
</A></li>
<LI>Next message: <A HREF="000100.html">[Mageia-webteam] Webteam peers, bootstrapping
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#98">[ date ]</a>
<a href="thread.html#98">[ thread ]</a>
<a href="subject.html#98">[ subject ]</a>
<a href="author.html#98">[ author ]</a>
</LI>
</UL>
<HR>
<!--beginarticle-->
<PRE>Le jeudi 06 janvier 2011 à 14:27 +0100, Romain d'Alverny a écrit :
><i> On Thu, Jan 6, 2011 at 13:19, Michael Scherer <<A HREF="https://www.mageia.org/mailman/listinfo/mageia-webteam">misc at zarb.org</A>> wrote:
</I>><i> > Le jeudi 06 janvier 2011 à 12:09 +0100, Romain d'Alverny a écrit :
</I>><i> >> What do peers have that non-peers do not?
</I>><i> >> [...]
</I>><i> > How are access to $VCS will be handled ?
</I>><i> >
</I>><i> > The possibility of having access to server to either read logs or run
</I>><i> > some limited commands was also asked, how would it articulate with this
</I>><i> > scheme ?
</I>><i>
</I>><i> I had written a § about it but thought it was too early here. Anyway,
</I>><i> here are my thoughts:
</I>><i>
</I>><i> * VCSes:
</I>><i> - read access for everyone (peers & non-peers);
</I>the easy part
><i> - write access for:
</I>><i> - webmasters (specific role, see below)
</I>so we need a group in ldap for that, i guess ?
><i> - app manager, who should in turn be able to provide a write
</I>><i> access to other peers (developers), on demand? if that's possible
</I>
everything is possible, but IMHO, question is "wouldn't it be better to
have one single group".
Historically at Mandriva, once you had commit right, you could commit
everywhere, and few problem arised from that. Same goes to gnome. I am
not keen on adding acl everywhere given the increased administrative
load it create ( for sysadmin as we either have to do it, or write some
delegation tools, for people who need to request before fixing anything,
and for app manager who need to approve requests ).
><i> - or for all peers, with each developer/app manager having a
</I>><i> careful look at what happens.
</I>><i> - or maybe it can be app-specific (depending on the app-criticity)
</I>><i> - of course, something making push/merge requests possible could
</I>><i> help (writable only by manager+webmasters, leaving everyone else push
</I>><i> changes to be merged after review)
</I>
I would let people decide, with a strong emphasis on letting people in
mga-commiters group by default. In 7 years at mdv, I never seen any
problem of mis commiting, and I think the potential problem a separation
would solve do not suffice to justify the cost.
Now, I only speak of a svn centric view and workflow, as for git, it
could be much more different ( or not ).
For git like all dvcs, we are slightly more free in term of workflow, as
explained for example here
<A HREF="http://doc.bazaar.canonical.com/bzr.1.18-html/en/user-guide/bazaar_workflows.html">http://doc.bazaar.canonical.com/bzr.1.18-html/en/user-guide/bazaar_workflows.html</A> .
And so I feel that industrialisation of project hosting ( as we are
somehow starting to do ) will be detrimental to the freedom of choice,
and we should agree on a few workflow before starting to deploy too much
things. ( ie, if we do want to automate thing, and that's one of the
sysadmin team goal ).
Deploying a simple git repository managed like a svn one would be easy
and fast. But that would be marginally better than git-svn.
Deploying a full system with workflow delegation is much more difficult,
but that's what we would want.
So a compromise would be to decide for 1 simple workflow, use for
everything in the first place, and postpone the deployment of a full
system to later.
><i> * server logs:
</I>><i> - read access to webmasters
</I>><i> - some limited commands? what type? rsync/svn/git types?
</I>
Well, limited command could be hard to achieve. I assume that read logs
is just "set permission properly" ( easy to do ). Limitation of command
could be done with sudo, but wouldn't change much if we give access to
shell.
><i> * server deployment:
</I>><i> - staging from a branch available to all peers
</I>><i> - production push from staging available to webmasters only
</I>
We can :
- use sudo + script + ldap group
- use $VCS based tags/branch + acl ( potentially based on ldap group
again )
><i> Webmasters are necessarily peers; they do master the whole websites,
</I>><i> deploy into production with the assistance of app developers (in
</I>><i> short, with sysadm, they are the ones having the production-push
</I>><i> button and the ability to check on logs). Of course, this requires
</I>><i> webmasters & sysadm to go along well. So sysadm would have at least a
</I>><i> consultative say on who can become a webmaster.
</I>><i>
</I>><i> At this time, this role is managed by (non-sysadm people): me and
</I>><i> damsweb for blog/www (editorial stuff), I believe all the rest is
</I>><i> pushed by sysadm at this time.
</I>
dams is sysadmin ( and I am picky, but sysadmin is the name of the team
in ldap, I do not know why people say sysadm everywhere, likely because
of the name of the list and irc channel :/ ).
So to summarize :
- external people
- webteam members
- webmasters
So 1st step, adding 2 group to ldap ?
--
Michael Scherer
</PRE>
<!--endarticle-->
<HR>
<P><UL>
<!--threads-->
<LI>Previous message: <A HREF="000105.html">[Mageia-webteam] Webteam peers, bootstrapping
</A></li>
<LI>Next message: <A HREF="000100.html">[Mageia-webteam] Webteam peers, bootstrapping
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#98">[ date ]</a>
<a href="thread.html#98">[ thread ]</a>
<a href="subject.html#98">[ subject ]</a>
<a href="author.html#98">[ author ]</a>
</LI>
</UL>
<hr>
<a href="https://www.mageia.org/mailman/listinfo/mageia-webteam">More information about the Mageia-webteam
mailing list</a><br>
</body></html>
|
