Thorsten Scherler wrote: > David Crossley escribi??: > > Thorsten Scherler wrote: > > > David Crossley escribi??: > > > > > > > > No need to have them all in SVN, just the one that > > > > we want to change. > > > > > > > > I see that Cocoon put all their config into the > > > > pmc/cocoon section of the private committers svn. > > > > > > Hmm, and how are they doing the checkout? > > > > At the moment it is actually the other way around. > > They maintain the files on the server, and a tar-it-up.sh > > to gather the important files, then a committer unpacks > > and adds it to svn. A temporary measure. > > Hmm, yeah a route that we should not go.
However it might make sense for these few secret files, to get around the problem that you describe below. > > > I thought the private stuff is > > > with password and we cannot checkout stuff with a user on zones. > > > > As long as the user is in the right group > > it will be fine. And as long as each user sets > > their umask properly. > > Hmm, you know that svn stores the password in a file? This means at > least sudo can look up all passwords if she wants. I see what you mean. However our committers are trusted and people only get sudo if they need it. Still you are right. I wonder how other projects do it. Perhaps a question for [EMAIL PROTECTED] Actually all the svn checkouts that i have done on the zone are anonymous checkouts, i.e. http and not https, so no password. However, that will not work for our section of the committers repository. > I thought that was > the reason why we could not set up a forrestbot on zones that is > actually as well deploying to our website. ??? Not really. The reason is that we cannot use a role-based account to do svn checkin. i.e. imagine that we wanted to have a special user called 'fb' and use that to run forrestbot and do 'svn ci'. We cannot because 'fb' is not a committer and so has no credentials. > > That module is private to "committers" so that > > should be okay. > > Yeah, still the password is stored on the server. > > > > > We should do the same for sensitive files like httpd.conf > > > > > > > > The main stuff would stay in our forrest/zones svn, > > > > because that is not sensitive and is of use to > > > > other people. > > > > > > Agree but I am not sure how you thought about it. > > > > Neither am i. > > ;-) > > > > > > > Either way, we will need a document to remind us of all about > > > > > > these specific symlinks and 'svn co'. I started something at > > > > > > f.a.o/zone.html > > > > > > > > > > I have not checked it in yet because we should decide first whether we > > > > > want to have /etc/apache2/ in our svn or only /etc/apache2/httpd.conf. > > > > > > > > > > I added it for now directly to /etc/apache2/httpd.conf and started the > > > > > server (which had been down). > > > > > > > > Glad that more people can now start the services. > > > > We need to listen to infra@ and realise it is down. > > > > > > Actually I submitted a patch to infrastructure to monitor lenya.zones > > > with http://monitoring.apache.org/status/ > > > > > > http://issues.apache.org/jira/browse/INFRA-698 > > > > > > If we want, I can do the same for forrest, then we know when it is down > > > and can react. > > > > Our http server should only be down if the whole > > zones machine has been rebooted. So IMO no need > > for monitoring. > > I have set up (again) a lenya instance on > http://lenya.zones.apache.org/index.html for us a while ago. I have not > told anyone till now because I hoped that my infra patch will be applied > and we could monitor the server right away. I did some testing with up > times and it seems to be fine this time. > http://lenya.zones.apache.org:9000/ > > But actually I would like to propose to set up a lenya instance on *our* > zones server (due to the fact that I am the only one in lenya ATM that > is looking out for the zone, it does not make any different to me to > support it directly here). I am keen that we slowly playing around with > lenya as cms and that we are independent from the lenya zone. Better propose that in a separate thread. Sounds like a good idea. That way other Forrest committers can help. > Further I would like to see as well a dynamic instance of forrest > running on zone (I plan to start a web gui for dynamically altering > structurer files) as show case. We need to first make sure that forrest is not a resource hog. This zone machine is shared with other users, and we don't want to get a bad name. > > > > Next step is to automate the startup. See the fixme > > > > note at http://forrest.apache.org/zone.html#admin > > > > > > Yeah on lenya we seem to have it because you cannot stop the httpd > > > without another one get up instantly. I will try to find the difference > > > between both configs. > > > > We don't have any config. As you can see we must start by > > hand after a reboot. > > I will try to set this up ASAP, since just today the server was down again (I > started it again). Okay, i presume that you mean 'smf'. -David
