Sylvain Beucler <[EMAIL PROTECTED]> tapota :
>> > Hi,
>> >
>> > I though that once a group was added to the system group file (such as
>> > /etc/group), the backend didn't try to install the
>> > repository/webpages/download area.
>> >
>> > It appears that all groups are 'recreated' each time you use
>> > sv_groups. I mean, the the system group file is left updated, but
>> > CvsMakeArea and other backend procedures are called.
>> >
>> > Usually this doesn't matter because CvsMakeArea & co exit when they
>> > see that the directory they plan to creat is already present. But this
>> > is no good for the way we update webpages at Savannah (ie ask the
>> > remote machine to update using a 'webservice' call).
>>
>> Sure, the backend as not really been designed to be run as a frontend
>> of something else. In other words, the backend should be theoretically
>> run on the machine that serves the webpages. Whatever.
>>
>> I do not really understand the exact problem you have, can you provide
>> more details?
>
> The way we have to update the www.gnu.org and www.nongnu.org webpages
> is to call a CGI script using curl that will trigger a checkout and
> update/create the remote webpages. They will then be updated by a
> cronjob at www.nongnu.org. So, if the CGI script is called during
> creation *and* each time sv_groups is launched at Savannah, it is not
> good for us. Above all, we do not know whether the webpages are
> already created or not, so we cannot stop calling the CGI scripts
> during later sv_groups executions.
This shows that this approach of cgi is a bit crappy, and that's
probably what should be fixed first.
But I'm pretty sure it's not up to you to change that. Funny to see
some project that got at most 4 servers to manage and that behave like
administrations that have 2000 servers to handle.
> But, what I am wondering is why calling CvsMakeArea & co at each
>sv_groups call. I considered those are useful only at project
>creation.
Simple example: project A is created and deactivate download
area. Download area is not created by sv_groups. At some point,
project A decide to use it. sv_groups create it. Project A estimate
his CVS tree content is fucked up and want to restart it from
scratch. An admin erase the cvs directory and sv_groups will recreate
it as it creates any other project CVS.
This way, you never enter case where you are forced to run manually
some commands to get the directories created.
And how the hell could it be a problem that each time sv_groups does a
check `unless -e $cvs_dir`?
sv_groups, when it was firstly installed on savannah.gnu.org, the
bi-PIII owned by FSF France, in the old days, was running in less than
6 minutes -- acceptable time for such cronjob.
Having a "clever" script that do trivial checks to make sure
everything is in order seems a good thing to me, especially when it
does not seems to clutter up the server.
Now, your problem is the fact that backend is itself a frontend for
another backend, and this late backend you have no control on, at all
-- you cannot even now if an action was succesful or not. In my
opinion, this is really a broken thing.
But I assume you cannot change that. So, to deal with this situation
far from the ideal one, I would that that you need a specific
CvsMakeArea, like CvsMakeAreaAttic.
CvsMakeAreaAttic is used at Gna! (the strange name of this sub is a
residual from the very start of Gna when the name was still undecided)
run CvsMakeArea and do extra commands.
Yours can run CvsMakeArea but call this only CGI only in some specific
cases. For instance, CvsMakeAreaAttic run gna specific stuff
(automatic configuration of mail notifications) only if CvsMakeArea
returned something true. But CvsMakeArea with return false if the CVS
directory was already existing.
I guess your CVS have to be called only at creation. So only if
CvsMakeArea return something true.
>> > Is this normal? It could actually be a bug in a boolean expression in
>> > "if ($no_etc && !$exists) { <do nothing> } else { <update system> }".
>>
>> No, this test have a completely different purpose (see the comment
>> that come along this test.
>
> I understood the reason of the first test.
>
> What I meant, is that maybe you intended to write something like:
> if ($no_etc && !$exists) { <do nothing> }
> elsif ($exists) { <do nothing> }
> else { <update system> }
>
> I still do some "boolean bugs" sometimes, so it could have been a bug
> :)
In fact, to understand that part of the code, you have to read the
code from the start of the section "Finally, update the system".
The test you mention is here to make sure that we never try to
update something if the group does not exists on the system while we
use the no_etc option.
If you do not use the no_etc option, there is no point in not taking
action: at this point in the script, exists would be meaningless, as
the script would have already taken care of creating the group.
So the only case where we rightfully disregard is really $no_etc &&
!$exists, as $exists alone is meaningless at this point of the script.
>
>> > Incidentally, this behavior also led my test install to reuse the
>> > existing "gnats" group from Debian, while not creating the associated
>> > "webgnats" one and ruining the 'gnats' project installation.
>>
>> The current CVS no longer mess with existing groups.
>
> I use the current CVS. Do you mean the current CERN branch?
No, I really mean the current CVS. But in fact, it does not mess with
users not created by Savane. But for groups, it can still actually
modify existing groups.
I have no clear thought about this. It is easy to determine whether a
user was creating by Savane. Not for groups.
--
Mathieu Roy
+---------------------------------------------------------------------+
| General Homepage: http://yeupou.coleumes.org/ |
| Computing Homepage: http://alberich.coleumes.org/ |
| Not a native english speaker: |
| http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english |
+---------------------------------------------------------------------+
_______________________________________________
Savane-dev mailing list
[EMAIL PROTECTED]
https://mail.gna.org/listinfo/savane-dev
