Enrique Vega <[EMAIL PROTECTED]> said:
> on 2/22/01 8:51 PM, Alan Knowles at [EMAIL PROTECTED] wrote:
>
> > Current documentation is on www.hklc.com/midgard_manual - under
staging/live -
> > the nadmin code is very close to M3 - which depends on CVS midgard - as
images
> > and our 'news' code is replication safe.
> > This inculdes
> > - sample repligard.conf files
> > - an perl script to generate apache conf files based on midgard host data.
> > - the repligard_withsg.xml definition.
> > - a script to downgrade the update times in the repligard table for
> > non-approved pages and dependants based on the approval record_extension.
> >
> > I will try and put some release notes together for M3 as it makes some
serious
> > changes to existing sites developed with nadmin. - I have a script that
goes
> > through all the HTML and replaces any refernce to attachments with the new
> > URL.
> > - We will be testing on a few more machines.
>
> Does "which depends on CVS midgard" mean that we need the newer php4 version
> of midgard? And if so, is there an rpm for redhat available yet?
>
At present, last nights CVS seems to be working on a test server, I have a few
more tests, then we will install it on our development server.
Basically 1.4.1 is very close... (if all goes well, I guess a week???????)
Nadmin will depend on this, as It includes code that ensure replicatable safe
sites.
> I'm also confused as to whether we should wait for the annoucement of M3
> before we try to use HKLC's replication files or if we can go ahead and set
> up staging/live replication as mentioned above.
You can try the snapshots - but they will only work on CVS midgard, and full
instructions wont be available until it is released.
(hint - there is a tools tab - use the convert images link in it)
>
> Speaking of attachments, are they handled differently now? If so, could you
> explain a little about the changes?
Previously attachments where url
/attachment/1/find/style/13/xyz.gif
(host= /attachment/1)
where 1 = sitegroup and 13 is the style id.
when replicating
-style 13 may not be the same style
-sitegroup 1 may not be the same sitegroup.
So the url has been changed to
/attachment/03al3lgvlkasu223l234/l2klasldu4asdofi243/xyz.gif
(host = /attachment/03al3lgvlkasu223l234)
where the
- the first set of letters/numbers is the Sitegroup GUID.
- the second set is the image's GUID
The filename is there just for readability purposes..
The script above is meant to convert all html too the new system. (It still
needs a bit of work... - but works in most situations where you do not copy
and paste HTML from style into pages.. - which we have seen)
>
> I'm really looking forward to setting up staging on my midgard web sites and
> am putting off any real development until the midgard php4 upgrade becomes
> available so replication of staging/live servers becomes a reality :-)
It does involve a bit of 'awareness' - pages that are approved (and their
images etc.) do not apppear on the 'real' site until they are approved (and
the cron job runs)
leads to questions 'I approved this, but it's not appearing'
> >>> Also, one additional intresting feature that I'm thinking about
> >>> would be sending notifications to authors when their articles
> >>> have been replicated to both servers. But this can easily be done
> >>> on the PHP level...
> >
> > Our script replicates on a single server - a bit more work is needed to
> > transfer the file across (rsync) to other servers and run import on them.
> >
> > I'm not sure about notifications. - this could be done at php level - but
it's
> > difficult to see how work out the conditions for this notification.....
> >
> > the replicate script would have to study what has been replicated, then
> > reverse lookup who was the owner and then send emails... - Perl sounds
like
> > the easiest solution here......
> >
> > The import wrapper script:
> > do the import
> > grep for action='update' read the GUID's from the repligard.xml.gz file
> > look up the info on the GUID from the repligard table in database
> > look up the owner's email from the database
> > send email....
> > delete xml.gz file..
I''ll stick it in the bug list
>
> God this would be great!!! Automatic notification would be a real +!
>
> Kudos to midgard, repligard, Aurora and HKLC!
>
> enrique
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
--
Technical Director
Linux Center (HK) Ltd.
www.hklc.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
