forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Noels <stev...@outerthought.org>
Subject forrestbot: security and trust
Date Fri, 12 Jul 2002 13:42:55 GMT
Warming up for the rehaul/update of our forrestbot which currently does 
automated builds of the Forrest website on http://www.krysalis.org/forrest/

What is in place currently:

- a Linux 'role' account that has a cron job configured which goes off 
every hour and calls this shell script:

#!/bin/sh

# needed by X
export DISPLAY=:1

# sets the location of the jdk
export JAVA_HOME=/usr/java/jdk1.3.1_02

# changes directory to where xml-forrest is
cd /xxx/xxx/roleaccount/xml-forrest

# updates xml-forrest from cvs
cvs -q update -dP

# calls the forrest target that generates and deploys the forrest site
# the output of the run goes to forrestbot.log
./build.sh clean updateforrestsite -Duse.skin=bert > forrestbot.log

As you see, it is very simple (and the only thing not committed to CVS 
for those who were worrying about that). Bad thing: it is a 'role' 
account, which is considered to be bad practice on 
infrastructure@apache.org.

Inside our build.xml file, you can find back some targets which use scp 
for transporting the build result to Krysalis and a ssh command that 
unpacks it and overwrites the existing site.

On the Krysalis side, there exists a role account user with the same 
name as on our side, and there is key-based password-less authentication 
  (ssh) between both. So basically our forrestbot can start an ssh/scp 
session with Krysalis without being prompted for a password, since its 
(passwordless) private key for Krysalis resides on our side.

OK. This works as long as we can keep our host uncompromized.

Next step.

We are going to do remote project docs building, presumably for Apache 
and non-Apache projects alike (Gump-style). The big difference however 
between Gump and Forrest is that Gump only reports (on a central 
location) and nags, whereas Forrest will distribute its results to other 
locations as well for updating those websites. Hence 
http://marc.theaimsgroup.com/?l=forrest-dev&m=102262745114246&w=2 where 
the configuration for a single project is described, but you can easily 
imagine other projects being specified in that file as well.

OK. Now for the 'trust' thing...

I've been looking into the ssh/scp documentation already, which would be 
the typical publishing protocol to be used, and it is possible to run 
those from a role/real account, pretending they are somebody else 
however, by specifying the location of the identity file (private key) 
and the username. I was much relieved by this ;-)

This however requires projects to trust Forrest, and to provide Forrest 
with a username/key combination that is able to access and update the 
remote website. And Forrest will need to safely manage those 
credentials, i.e. if the box where the central Forrest service runs on 
is compromised, a lot of websites potentially could be defaced :-s

What do you think? Is it feasible to work in this direction? Point is 
that this would offer our users with a true headless/handsfree 
environment, which is my personal pet peeve. Other option would be that 
each group of projects has its own box, a forrestbot installed with 
credentials to access/update the entire collection of documentation 
sources and website. This might be feasible in the xml.apache.org 
context, but I wouldn't mind hosting/building other projects as well, 
IMO. OTOH, having a federation of forrestbots for specific software 
project groups sounds sensible, too.

Regards,

</Steven>
-- 
Steven Noels                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
stevenn@outerthought.org                      stevenn@apache.org


Mime
View raw message