> Les Mikesell wrote:
> > But if you care about version control, you must include the parts of
> > code/configuration involved in your repository.
>
> No, you put development versions of the configuration in the
> developer's
> SVN. Not operations. And you have ways to override stuff.
>
> > They are often need to be included in a file of code or configuration
> > that is someone else's design. Bad design or not
>
> Its a very bad design. Again, if you care about security, you have no
> choice.
>
> >> Most theft and fraud are inside jobs. You can not allow simple
> access to
> >> the source code to allow access to production.
> >
> > Nor is it a good idea to put things into production that aren't under
> > version control.
>
> I did not say use nothing on the production side.
>
> What I said was that developers have zero access to the production
> configuration. They have access to the developement and/or testing
> configuration
>
> Ops can have their own SVN, but no access from the development
> engineers
>
>
> >> This does not prevent the operations folks from having their own SVN
> >> inside their security perimeter. But its simply wrong to put
> production
> >> passwords in the general engineering SVN.
> >
> > So how do you roll out code/configurations to a bunch of machines
> with
> > the ability to roll back without storing it somewhere that the people
> > who develop/test it can access?
>
> You seem to be thinking that development engineers are allowed to touch
> production. That is not how secure or even well run sites are operated.
Some of this stuff also depends on what you are storing. Perhaps going another way would be better. For example, use NT Authentication to access your SQL servers rather than username/password. This way, the password isn't in the configuration file. I am sure there are similar LDAP type ways to deal with this for other technologies also.
BOb
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2403027
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-10-02 20:08:58 CEST