RE: copying subdirectories in subversion 1.7

2011-07-25 Thread Feldhacker, Chris
  I wonder if people will expect a script named detach to copy or do they 
 think it will move?

More like extract or promote -- promoting a child folder to become a 
full-fledged, independent working copy...

liberate?  Kinda like that...  :-)


-Message Disclaimer-

This e-mail message is intended only for the use of the individual or
entity to which it is addressed, and may contain information that is
privileged, confidential and exempt from disclosure under applicable law.
If you are not the intended recipient, any dissemination, distribution or
copying of this communication is strictly prohibited. If you have
received this communication in error, please notify us immediately by
reply email to conn...@principal.com and delete or destroy all copies of
the original message and attachments thereto. Email sent to or from the
Principal Financial Group or any of its member companies may be retained
as required by law or regulation.

Nothing in this message is intended to constitute an Electronic signature
for purposes of the Uniform Electronic Transactions Act (UETA) or the
Electronic Signatures in Global and National Commerce Act (E-Sign)
unless a specific statement to the contrary is included in this message.

While this communication may be used to promote or market a transaction
or an idea that is discussed in the publication, it is intended to provide
general information about the subject matter covered and is provided with
the understanding that The Principal is not rendering legal, accounting,
or tax advice. It is not a marketed opinion and may not be used to avoid
penalties under the Internal Revenue Code. You should consult with
appropriate counsel or other advisors on all matters pertaining to legal,
tax, or accounting obligations and requirements.



RE: How to control changes to path-based auth file?

2011-05-09 Thread Feldhacker, Chris
In a nutshell:  http://www.svn-access-manager.org/

Basically, store all your settings in a database and generate the config files; 
just use a simple web front-end to edit the database and control/log changes 
that way.  The svn access manager provides a good starting point, modify and 
tweak as needed.




-Original Message-
From: Cooke, Mark [mailto:mark.co...@siemens.com] 
Sent: Monday, May 09, 2011 11:19 AM
To: users@subversion.apache.org
Subject: How to control changes to path-based auth file?

Dear list,

I was wondering how other (probably corporate?) svn users control and log 
changes to your path-based auth file (and other svn web settings)?

I was thinking that I could use svn and the auto-website-update FAQ
(http://subversion.apache.org/faq.html#website-auto-update) to control access 
by allowing named users access to the relevant repo...  However this seems a 
little clunky and 'overkill' for what we have.

We also use `Trac` and there are a couple of trac-hacks:
 * http://trac-hacks.org/wiki/SvnAuthzAdminPlugin
 * http://trac-hacks.org/wiki/TracSvnAuthzPlugin
...that enable editing of the path-based-auth file through Trac but neither 
include any versioning (for auditing purposes).

Can anyone recommend any other routes?

For information, we use Trac and subversion, served from windows server via 
apache...

Many thanks,

~ mark c


-Message Disclaimer-

This e-mail message is intended only for the use of the individual or
entity to which it is addressed, and may contain information that is
privileged, confidential and exempt from disclosure under applicable law.
If you are not the intended recipient, any dissemination, distribution or
copying of this communication is strictly prohibited. If you have
received this communication in error, please notify us immediately by
reply email to conn...@principal.com and delete or destroy all copies of
the original message and attachments thereto. Email sent to or from the
Principal Financial Group or any of its member companies may be retained
as required by law or regulation.

Nothing in this message is intended to constitute an Electronic signature
for purposes of the Uniform Electronic Transactions Act (UETA) or the
Electronic Signatures in Global and National Commerce Act (E-Sign)
unless a specific statement to the contrary is included in this message.

While this communication may be used to promote or market a transaction
or an idea that is discussed in the publication, it is intended to provide
general information about the subject matter covered and is provided with
the understanding that The Principal is not rendering legal, accounting,
or tax advice. It is not a marketed opinion and may not be used to avoid
penalties under the Internal Revenue Code. You should consult with
appropriate counsel or other advisors on all matters pertaining to legal,
tax, or accounting obligations and requirements.



RE: Understanding merging

2011-03-08 Thread Feldhacker, Chris
 
-Original Message-
From: Steve Cohen [mailto:stevec...@comcast.net] 
Sent: Tuesday, March 08, 2011 12:20 PM
To: users@subversion.apache.org
Subject: Understanding merging

 I work with a very senior colleague who has never always resisted version 
 control and would much rather do without it, but he is forced to go along and 
 I am the whipping boy whenever something goes wrong.
 He poses a general but simple question that I find myself unable to give a 
 simple answer to.  I am rephrasing it slightly but it bothers me that I don't 
 know the simple answer.  If I found myself in this situation I would tweak 
 until it was as desired, but my persnickety colleague is not satisfied with 
 such answers and for once, I don't blame him.
 Given two branches off a trunk that were taken at different times, if the 
 first is merged back to the trunk and then the second, how may the second be 
 merged back into the trunk so as not to override changes from the first 
 merge, assuming that both change sets are desired to be in the trunk at the 
 end?



Do the branches receive updates from trunk or not?
If the answer is yes, then before merging a branch back to trunk, one final 
update from trunk to the branch must be performed.  The branch is now 
up-to-date with trunk, and (ideally) the changes on the branch should be 
retested to make sure everything works.  When ready, the branch is merged using 
the reintegrate option back to the trunk.  Using reintegrate, the 
differences between the branch and the trunk are computed and the changes 
applied to the trunk.

If the answer is no, then when the changes on the branch are ready to be merged 
back to the trunk the reintegrate option must NOT be used.  Without 
reintegrate, the changes made on the branch are collected and effectively 
replayed on the trunk, which will have the desired result regardless of 
whether or not additional changes to trunk have already been made.

So, a specific decision must be made as to whether or not reintegrate should 
be used, and the correct answer depends on whether or not the branch receives 
updates from trunk during its life.  

As long as the correct choice is made each time a branch is merged, then no 
changes will be undone or overridden.

(It would be really nice if Subversion could detect that a branch has received 
updates from the origin and follow the best practice of do the right thing by 
default, but...it is what it is!)






-Message Disclaimer-

This e-mail message is intended only for the use of the individual or
entity to which it is addressed, and may contain information that is
privileged, confidential and exempt from disclosure under applicable law.
If you are not the intended recipient, any dissemination, distribution or
copying of this communication is strictly prohibited. If you have
received this communication in error, please notify us immediately by
reply email to conn...@principal.com and delete or destroy all copies of
the original message and attachments thereto. Email sent to or from the
Principal Financial Group or any of its member companies may be retained
as required by law or regulation.

Nothing in this message is intended to constitute an Electronic signature
for purposes of the Uniform Electronic Transactions Act (UETA) or the
Electronic Signatures in Global and National Commerce Act (E-Sign)
unless a specific statement to the contrary is included in this message.

While this communication may be used to promote or market a transaction
or an idea that is discussed in the publication, it is intended to provide
general information about the subject matter covered and is provided with
the understanding that The Principal is not rendering legal, accounting,
or tax advice. It is not a marketed opinion and may not be used to avoid
penalties under the Internal Revenue Code. You should consult with
appropriate counsel or other advisors on all matters pertaining to legal,
tax, or accounting obligations and requirements.



RE: Subversion Apache2.2 LDAPS authentication failed

2011-02-28 Thread Feldhacker, Chris
-Original Message-
From: 金健康 [mailto:jinjiankang1...@gmail.com] 
Sent: Friday, February 25, 2011 12:53 AM
To: users@subversion.apache.org
Subject: Subversion Apache2.2 LDAPS authentication failed

Hi,

OS: Redhat Linux
Subversion: 1.5.0
Apache: 2.2.17
OpenLDAP: 2.3.27

httpd.conf:
...
LDAPSharedCacheSize 20
LDAPCacheEntries 1024
LDAPCacheTTL 600
LDAPOpCacheEntries 1024
LDAPOpCacheTTL 600

Location /svn
DAV svn
SVNParentPath /home/svnroot/repository
AuthzSVNAccessFile /home/svnroot/repository/svn_access_file
AuthType Basic
AuthBasicProvider ldap
AuthzLDAPAuthoritative off
AuthLDAPURL 
ldaps://master.ldap.ebupt.com:636/OU=staff,DC=ebupt,DC=com?uid?sub?(objectClass=*)
SS
L
AuthName Subversion.resository
Require valid-user
/Location
...

Apache error_log:

[Thu Feb 24 16:48:00 2011] [debug] mod_authnz_ldap.c(403): [client 10.1.85.181] 
[25242] auth_ldap a
uthenticate: using URL
ldaps://master.ldap.ebupt.com:636/OU=staff,DC=ebupt,DC=com?uid?sub?(objectCl
ass=*)
[Thu Feb 24 16:48:00 2011] [info] [client 10.1.85.181] [25242] auth_ldap 
authenticate: user jinjian kang authentication failed; URI /svn [LDAP: 
ldap_simple_bind_s() failed][Can't contact LDAP server]

ping master.ldap.ebupt.com is OK.

My FTP LDAPS authentication is OK as below:
server:master.ldap.ebupt.com
port:636 Enable
SSL:checked
Base DN:ou=staff,dc=ebupt,dc=com
anonymous bind:checked
Search Filter:(objectClass=*)
User DN attribute:uid
Search scope:subtree

Thanks.
Jin Jiankang



I don't see any LDAPTrustedGlobalCert entries that tell Apache how to verify 
the server certificate...  Have you defined any in the config file?
http://httpd.apache.org/docs/2.2/mod/mod_ldap.html

Otherwise, you could also try adding this directive to see if it has any affect:
LDAPVerifyServerCert Off

Other than checking to verify the host name matches what's in the certificate, 
and making sure the CAs are setup, you could also check out this message:
http://subversion.open.collab.net/ds/viewMessage.do?dsForumId=3dsMessageId=395193

FWIW!







-Message Disclaimer-

This e-mail message is intended only for the use of the individual or
entity to which it is addressed, and may contain information that is
privileged, confidential and exempt from disclosure under applicable law.
If you are not the intended recipient, any dissemination, distribution or
copying of this communication is strictly prohibited. If you have
received this communication in error, please notify us immediately by
reply email to conn...@principal.com and delete or destroy all copies of
the original message and attachments thereto. Email sent to or from the
Principal Financial Group or any of its member companies may be retained
as required by law or regulation.

Nothing in this message is intended to constitute an Electronic signature
for purposes of the Uniform Electronic Transactions Act (UETA) or the
Electronic Signatures in Global and National Commerce Act (E-Sign)
unless a specific statement to the contrary is included in this message.

While this communication may be used to promote or market a transaction
or an idea that is discussed in the publication, it is intended to provide
general information about the subject matter covered and is provided with
the understanding that The Principal is not rendering legal, accounting,
or tax advice. It is not a marketed opinion and may not be used to avoid
penalties under the Internal Revenue Code. You should consult with
appropriate counsel or other advisors on all matters pertaining to legal,
tax, or accounting obligations and requirements.


RE: SVN group authentication to AD

2010-11-15 Thread Feldhacker, Chris
 dpb is a member of IT-InfrastructureTeam-SystemAdministrator-R and 
 IT-InfrastructureTeam-SystemAdministrator-R is a member of 
 SVN-Puppet-ReadWrite-P AD group
 

Nested AD groups aren't supported -- not many products do.  Typically, support 
for nested AD groups requires that the client application use the native AD 
APIs rather than generic LDAP APIs.  





From: Dale Bohl [mailto:db...@masoncompaniesinc.com] 
Sent: Monday, November 15, 2010 7:40 AM
To: users@subversion.apache.org
Subject: SVN group authentication to AD



Hello,

 

I've been banging my head on this one for 2 days now.

I've googled this issue but it appears not many admins are using this and/or

it could possibly be a bug in the apache module.

 

Config

--

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

Server version: Apache/2.2.3

svn, version 1.6.12 (r955767)

Windows 2008 R2

 

   It appears that we cannot use Active Directory Permissions Groups

with the s-svn server for Subversion repository authentication and authorization

but yet AD Role groups work just fine.

 

subversion.conf config for puppet repository



#puppet repo===

Location /puppet

   DAV svn

   SVNPath /repos/puppet

   AuthPAM_Enabled on

   AuthType Basic

   AuthName Subversion Authentication to AD

 

   # Limit R/W access to certain role groups

   LimitExcept GET PROPFIND OPTIONS REPORT

#  Require group SVN-Puppet-ReadWrite-P

  Require group IT-InfrastructureTeam-SystemAdministrator-R

   /LimitExcept

 

   # Limit R/O access to certain role group

   Limit GET PROPFIND OPTIONS REPORT

#  Require group SVN-Puppet-ReadWrite-P

  Require group IT-InfrastructureTeam-SystemAdministrator-R

   /Limit

/Location

 

The interesting thing is that AD Role Groups appear to work fine within

the Location directive config above which shows the role group for which

I'm a member.

 

If the above config is changed to use the Permissions group shown commented

out, authentication doesn't work and when that happens I'm seeing the following

error in ssl_error_log.

 

[Fri Nov 12 13:10:18 2010] [error] [client 172.16.4.7] GROUP: dpb not in 
required group(s).

 

So, even though the following User  Role  Permissions  Resource association

exists, the group with '-P' in it above won't allow dpb to authenticate for 
repo access.

 

dpb is a member of IT-InfrastructureTeam-SystemAdministrator-R and

IT-InfrastructureTeam-SystemAdministrator-R is a member of 
SVN-Puppet-ReadWrite-P AD

group

 

Any help would be greatly appreciated.

 



Dale Bohl
Sr. Systems Administrator
Mason Companies, Inc.
db...@masoncompaniesinc.com mailto:db...@masoncompaniesinc.com 
(715)-720-4382

 



-Message Disclaimer-

This e-mail message is intended only for the use of the individual or
entity to which it is addressed, and may contain information that is
privileged, confidential and exempt from disclosure under applicable law.
If you are not the intended recipient, any dissemination, distribution or
copying of this communication is strictly prohibited. If you have
received this communication in error, please notify us immediately by
reply email to conn...@principal.com and delete or destroy all copies of
the original message and attachments thereto. Email sent to or from the
Principal Financial Group or any of its member companies may be retained
as required by law or regulation.

Nothing in this message is intended to constitute an Electronic signature
for purposes of the Uniform Electronic Transactions Act (UETA) or the
Electronic Signatures in Global and National Commerce Act (E-Sign)
unless a specific statement to the contrary is included in this message.

While this communication may be used to promote or market a transaction
or an idea that is discussed in the publication, it is intended to provide
general information about the subject matter covered and is provided with
the understanding that The Principal is not rendering legal, accounting,
or tax advice. It is not a marketed opinion and may not be used to avoid
penalties under the Internal Revenue Code. You should consult with
appropriate counsel or other advisors on all matters pertaining to legal,
tax, or accounting obligations and requirements.



RE: SVN group authentication to AD

2010-11-15 Thread Feldhacker, Chris
Sorry -- disregard my post.  

I overlooked the Auth_PAMEnabled line and assumed you were using the standard 
LDAP authz Apache modules, which don't support nested groups.

However, while you're waiting for someone with more PAM knowledge to reply, I 
would wonder if perhaps the cause could be similar -- I would check the 
documentation for the specific PAM module you are using and verify nested 
groups are supported...



-Original Message-
From: Feldhacker, Chris [mailto:feldhacker.ch...@principal.com] 
Sent: Monday, November 15, 2010 7:50 AM
To: Dale Bohl
Cc: users@subversion.apache.org
Subject: RE: SVN group authentication to AD

 dpb is a member of IT-InfrastructureTeam-SystemAdministrator-R and 
 IT-InfrastructureTeam-SystemAdministrator-R is a member of 
 SVN-Puppet-ReadWrite-P AD group
 

Nested AD groups aren't supported -- not many products do.  Typically, support 
for nested AD groups requires that the client application use the native AD 
APIs rather than generic LDAP APIs.  





From: Dale Bohl [mailto:db...@masoncompaniesinc.com]
Sent: Monday, November 15, 2010 7:40 AM
To: users@subversion.apache.org
Subject: SVN group authentication to AD



Hello,

 

I've been banging my head on this one for 2 days now.

I've googled this issue but it appears not many admins are using this and/or

it could possibly be a bug in the apache module.

 

Config

--

Red Hat Enterprise Linux Server release 5.5 (Tikanga)

Server version: Apache/2.2.3

svn, version 1.6.12 (r955767)

Windows 2008 R2

 

   It appears that we cannot use Active Directory Permissions Groups

with the s-svn server for Subversion repository authentication and authorization

but yet AD Role groups work just fine.

 

subversion.conf config for puppet repository



#puppet repo===

Location /puppet

   DAV svn

   SVNPath /repos/puppet

   AuthPAM_Enabled on

   AuthType Basic

   AuthName Subversion Authentication to AD

 

   # Limit R/W access to certain role groups

   LimitExcept GET PROPFIND OPTIONS REPORT

#  Require group SVN-Puppet-ReadWrite-P

  Require group IT-InfrastructureTeam-SystemAdministrator-R

   /LimitExcept

 

   # Limit R/O access to certain role group

   Limit GET PROPFIND OPTIONS REPORT

#  Require group SVN-Puppet-ReadWrite-P

  Require group IT-InfrastructureTeam-SystemAdministrator-R

   /Limit

/Location

 

The interesting thing is that AD Role Groups appear to work fine within

the Location directive config above which shows the role group for which

I'm a member.

 

If the above config is changed to use the Permissions group shown commented

out, authentication doesn't work and when that happens I'm seeing the following

error in ssl_error_log.

 

[Fri Nov 12 13:10:18 2010] [error] [client 172.16.4.7] GROUP: dpb not in 
required group(s).

 

So, even though the following User  Role  Permissions  Resource association

exists, the group with '-P' in it above won't allow dpb to authenticate for 
repo access.

 

dpb is a member of IT-InfrastructureTeam-SystemAdministrator-R and

IT-InfrastructureTeam-SystemAdministrator-R is a member of 
SVN-Puppet-ReadWrite-P AD

group

 

Any help would be greatly appreciated.

 



Dale Bohl
Sr. Systems Administrator
Mason Companies, Inc.
db...@masoncompaniesinc.com mailto:db...@masoncompaniesinc.com 
(715)-720-4382

 



-Message Disclaimer-

This e-mail message is intended only for the use of the individual or
entity to which it is addressed, and may contain information that is
privileged, confidential and exempt from disclosure under applicable law.
If you are not the intended recipient, any dissemination, distribution or
copying of this communication is strictly prohibited. If you have
received this communication in error, please notify us immediately by
reply email to conn...@principal.com and delete or destroy all copies of
the original message and attachments thereto. Email sent to or from the
Principal Financial Group or any of its member companies may be retained
as required by law or regulation.

Nothing in this message is intended to constitute an Electronic signature
for purposes of the Uniform Electronic Transactions Act (UETA) or the
Electronic Signatures in Global and National Commerce Act (E-Sign)
unless a specific statement to the contrary is included in this message.

While this communication may be used to promote or market a transaction
or an idea that is discussed in the publication, it is intended to provide
general information about the subject matter covered and is provided with
the understanding that The Principal is not rendering legal, accounting,
or tax advice. It is not a marketed opinion and may not be used to avoid
penalties under the Internal Revenue Code. You should consult with
appropriate counsel or other advisors on all matters pertaining to legal,
tax

RE: History of a fixed path across all objects

2010-11-10 Thread Feldhacker, Chris
I think you want the --ignore-ancestry option:

http://svnbook.red-bean.com/nightly/en/svn.ref.svn.html#svn.ref.svn.sw




-Original Message-
From: Klaus Ganser [mailto:kgan...@gmail.com] 
Sent: Wednesday, November 10, 2010 1:37 PM
To: David Weintraub
Cc: users@subversion.apache.org
Subject: Re: History of a fixed path across all objects

On Wed, Nov 10, 2010 at 11:32 AM, David Weintraub qazw...@gmail.com wrote:

 You want the entire history of a file called bar.java in the path 
 /foo/bar/barfoo from revision #1 to the current revision -- even 
 though it isn't the same bar.java at that location?

 Is this correct?

Yes, that is correct.


-Message Disclaimer-

This e-mail message is intended only for the use of the individual or
entity to which it is addressed, and may contain information that is
privileged, confidential and exempt from disclosure under applicable law.
If you are not the intended recipient, any dissemination, distribution or
copying of this communication is strictly prohibited. If you have
received this communication in error, please notify us immediately by
reply email to conn...@principal.com and delete or destroy all copies of
the original message and attachments thereto. Email sent to or from the
Principal Financial Group or any of its member companies may be retained
as required by law or regulation.

Nothing in this message is intended to constitute an Electronic signature
for purposes of the Uniform Electronic Transactions Act (UETA) or the
Electronic Signatures in Global and National Commerce Act (E-Sign)
unless a specific statement to the contrary is included in this message.

While this communication may be used to promote or market a transaction
or an idea that is discussed in the publication, it is intended to provide
general information about the subject matter covered and is provided with
the understanding that The Principal is not rendering legal, accounting,
or tax advice. It is not a marketed opinion and may not be used to avoid
penalties under the Internal Revenue Code. You should consult with
appropriate counsel or other advisors on all matters pertaining to legal,
tax, or accounting obligations and requirements.



RE: History of a fixed path across all objects

2010-11-10 Thread Feldhacker, Chris
-Original Message-
From: Klaus Ganser [mailto:kgan...@gmail.com] 
Sent: Wednesday, November 10, 2010 2:43 PM
To: Feldhacker, Chris
Cc: users@subversion.apache.org
Subject: Re: History of a fixed path across all objects

 On Wed, Nov 10, 2010 at 12:19 PM, Feldhacker, Chris 
 feldhacker.ch...@principal.com wrote:
 I think you want the --ignore-ancestry option:

 svn log does not support that option.


Ah, my bad.  The ignore ancestry option can be used when merging to handle 
delete-recreate scenarios (it treats the resources as the same), but SVN is not 
(yet!?) smart enough to be able to use the ignore ancestry option when 
viewing the log...

Good question.  Sounds like a good feature request...


-Message Disclaimer-

This e-mail message is intended only for the use of the individual or
entity to which it is addressed, and may contain information that is
privileged, confidential and exempt from disclosure under applicable law.
If you are not the intended recipient, any dissemination, distribution or
copying of this communication is strictly prohibited. If you have
received this communication in error, please notify us immediately by
reply email to conn...@principal.com and delete or destroy all copies of
the original message and attachments thereto. Email sent to or from the
Principal Financial Group or any of its member companies may be retained
as required by law or regulation.

Nothing in this message is intended to constitute an Electronic signature
for purposes of the Uniform Electronic Transactions Act (UETA) or the
Electronic Signatures in Global and National Commerce Act (E-Sign)
unless a specific statement to the contrary is included in this message.

While this communication may be used to promote or market a transaction
or an idea that is discussed in the publication, it is intended to provide
general information about the subject matter covered and is provided with
the understanding that The Principal is not rendering legal, accounting,
or tax advice. It is not a marketed opinion and may not be used to avoid
penalties under the Internal Revenue Code. You should consult with
appropriate counsel or other advisors on all matters pertaining to legal,
tax, or accounting obligations and requirements.



RE: locking down access to a repository

2010-11-09 Thread Feldhacker, Chris
 But if I remove that line then no one can access the repository
 
Most likely because something else in the configuration isn't quite right...  I 
would suggest setting things up and testing with one LDAP server at a time to 
verify the configuration of each before trying to combine them.
 
Location /svn
  AuthName Subversion Server
  AuthType Basic
  AuthBasicAuthoritative On
  AuthBasicProvider ldap
 
  # If ldap checks are used with non-ldap (valid-user), set this to off
  AuthzLDAPAuthoritative off
  AuthLDAPURL 
ldaps://gc.company.com:3269/DC=domain,DC=comp,DC=company,DC=com?sAMAccountName?sub?(objectCategory=user)
  AuthLDAPBindDN CN=ADMIN,OU=Users,DC=domain,DC=comp,DC=company,DC=com
  AuthLDAPBindPassword pa$$w0rd
/Location

Location /svn/bu/repo1
 DAV svn
 SVNPath /Repositories/bu/repo1
 SVNPathAuthz off
 #1 The following users/groups will have read-write permission
 Require ldap-group 
CN=REPO1_USERS,OU=Groups,DC=domain,DC=comp,DC=company,DC=com
 Require ldap-group CN=Admins,OU=Groups,DC=domain,DC=comp,DC=company,DC=com
 Require ldap-user someid
 
 Limit GET PROPFIND OPTIONS REPORT
 #2 For any read-only operation, allow these additional users/groups
Require valid-user
 /Limit
/Location
 

I know this works. After the #1 line, add Require directives for all the 
groups/users that should read-write access.  After the #2 line, add any 
Require directives for any groups/users that should also have read-only 
access.  In this example, Require valid-user is used to mean that any 
authenticated user has read-only access to the repository.
The first Location block must come first; repeat the second Location block as 
many times as necessary for each repository.
 



From: Patricia A Moss [mailto:pmo...@csc.com] 
Sent: Tuesday, November 09, 2010 9:42 AM
To: kmra...@rockwellcollins.com
Cc: users@subversion.apache.org
Subject: Re: locking down access to a repository



I don't think you want the Require valid-user line, since by default it uses 
ANY of the Require lines as matches.  (And in your case valid-user matches all 
users so it doesn't care you are also specifying a group and an user.) 

But if I remove that line then no one can access the repository. 


PATI MOSS
System Engineer Sr. Professional
CSC





From:   kmra...@rockwellcollins.com 
To: Patricia A Moss/USA/c...@csc 
Cc: users@subversion.apache.org 
Date:   11/09/2010 10:38 AM 
Subject:Re: locking down access to a repository






Stefan Sperling s...@elego.de wrote on 11/09/2010 08:34:37 AM:
  I've configured my ldap aliases as follows:
  AuthnProviderAlias ldap ldap-FCGNET
  AuthLDAPBindDN FCGNET\svnuser
  AuthLDAPBindPassword x
  AuthLDAPURL 
  ldap://xx.fcg.com:3268/DC=fcg,DC=com?samAccountName?sub?
  (objectCategory=person)
  /AuthnProviderAlias
  AuthnProviderAlias ldap ldap-VIET
  AuthLDAPBindDN CN=fcgvuser,OU=Service 
  Accounts,OU=Users,OU=Production,DC
  =vdc,DC=csc,DC=com
  AuthLDAPBindPassword xxx
  AuthLDAPURL ldap://x.vdc.csc.com:3268/DC=vdc,DC=csc,DC=com?sa
  mAccountName?sub?(objectCategory=person)
  /AuthnProviderAlias
  
  Then in each, specific repositorry configuration file, I have the 
  following:
  Location /FDCertifications
  dav svn
  SVNPath /disk01/home/FDCertifications
  AuthType Basic
  AuthBasicProvider ldap-FCGNET ldap-VIET
  AuthzLDAPAuthoritative off
  AuthName CSC Subversion Repository
  Require valid-user
  Require ldap-group CN=PRJ 
  FDCertifications,OU=Europe,OU=Groups,DC=fcg,DC=com
  Require ldap-user pmoss
  /Location

I don't think you want the Require valid-user line, since by default it uses 
ANY of the Require lines as matches.  (And in your case valid-user matches all 
users so it doesn't care you are also specifying a group and an user.) 

Kevin R. 




-Message Disclaimer-

This e-mail message is intended only for the use of the individual or
entity to which it is addressed, and may contain information that is
privileged, confidential and exempt from disclosure under applicable law.
If you are not the intended recipient, any dissemination, distribution or
copying of this communication is strictly prohibited. If you have
received this communication in error, please notify us immediately by
reply email to conn...@principal.com and delete or destroy all copies of
the original message and attachments thereto. Email sent to or from the
Principal Financial Group or any of its member companies may be retained
as required by law or regulation.

Nothing in this message is intended to constitute an Electronic signature
for purposes of the Uniform Electronic Transactions Act (UETA) or the
Electronic Signatures in Global and National Commerce Act (E-Sign)
unless a specific statement to the contrary is included in this message.

While this communication may be used to promote or market a transaction
or 

Global ignores

2010-10-07 Thread Feldhacker, Chris
Where can I find more complete information on global-ignores and the expected 
format/syntax of the patterns?

The svnbook just indicates:
The global-ignores option is a list of whitespace-delimited globs which 
describe the names of files and directories that Subversion should not display 
unless they are versioned. 
The default value is *.o *.lo *.la #*# .*.rej *.rej .*~ *~ .#* .DS_Store

At first I assumed this just performed wild-card matching, but looking at the 
default list within the config file that was created on my machine (Windows) I 
see this:

global-ignores = *.o *.lo *.la *.al .libs *.so *.so.[0-9]* *.a *.pyc *.pyo
   *.rej *~ #*# .#* .*.swp .DS_Store

Based on the presence of the [0-9] set, I assume something a bit more than 
just wild-card matching must be performed but apparently something less than 
full regular expressions...

The wikipedia entry for glob indicates this is just a generic term that 
refers to a limited pattern-matching facility, which seems to vary by 
programming language or shell, and there is no definite syntax for globs...


So, where can I find more complete information on the glob syntax that 
Subversion uses for the global-ignores option, and is it consistent across OSes?
Thanks!



-Message Disclaimer-

This e-mail message is intended only for the use of the individual or
entity to which it is addressed, and may contain information that is
privileged, confidential and exempt from disclosure under applicable law.
If you are not the intended recipient, any dissemination, distribution or
copying of this communication is strictly prohibited. If you have
received this communication in error, please notify us immediately by
reply email to conn...@principal.com and delete or destroy all copies of
the original message and attachments thereto. Email sent to or from the
Principal Financial Group or any of its member companies may be retained
as required by law or regulation.

Nothing in this message is intended to constitute an Electronic signature
for purposes of the Uniform Electronic Transactions Act (UETA) or the
Electronic Signatures in Global and National Commerce Act (E-Sign)
unless a specific statement to the contrary is included in this message.

While this communication may be used to promote or market a transaction
or an idea that is discussed in the publication, it is intended to provide
general information about the subject matter covered and is provided with
the understanding that The Principal is not rendering legal, accounting,
or tax advice. It is not a marketed opinion and may not be used to avoid
penalties under the Internal Revenue Code. You should consult with
appropriate counsel or other advisors on all matters pertaining to legal,
tax, or accounting obligations and requirements.



RE: [ANNOUNCE] svnrdump: A new dumper/ loader in trunk

2010-08-19 Thread Feldhacker, Chris
Any rough documentation available, particularly in terms of security or 
access control?

Remote dump makes sense -- and I assume everything being dumped is subject to 
the authorization/access control restrictions that have been put into place on 
the server, yes?  (A particular path or file won't be included in the dump if 
the user doesn't have permission to access it, right?)

Remote load seems scary -- How can I prevent my users from being able to use 
this command?  Is the original author of the dumped revision preserved, or is 
the author set to the user doing the load?  Can users do anything else bad, 
like changing repo UUID?

Right now svnadmin is great because performing admin functions is controlled by 
requiring actual access to the box.  If admin functions are now going to be 
available remotely, then I would want to make sure there was a way to make sure 
these functions could only be performed by authorized users...



-Original Message-
From: Ramkumar Ramachandra [mailto:artag...@gmail.com] 
Sent: Wednesday, August 18, 2010 1:51 PM
To: Subversion Users Mailing List
Cc: Daniel Shahaf; Bert Huijben; Stefan Sperling
Subject: [ANNOUNCE] svnrdump: A new dumper/ loader in trunk

Hi,

There's now a new tool located in subversion/svnrdump. We have developed it 
over the last few weeks, and we feel that it is mature enough to announce. 
Although it has not been tested extensively, we would like to encourage you to 
try it out and give us feedback so we can improve it.

So what is svnrdump? It is a tool to produce a dumpfile from a remote 
repository without having to mirror the whole thing on the hard disk, as well 
as load a dumpfile into a remote repository. Although it's fundamentally 
different from the `svnadmin` tool on the inside, it can be thought of as 
providing a remote `svnadmin dump | load` functionality. It currently only 
works with dumpfile v3, and we intend to keep it that way.

svnrdump is meant to be a lightweight high-performance tool that is intended to 
be useful to both server admins and developers of other versioning systems 
looking to import/ export revision history from Subversion. The motivation for 
the project actually arises from my recent GSoC project, git-remote-svn; the 
Git developers are writing in support for seamless interoperability with 
Subversion.

Anyway, we hope you find the tool useful; do test it on your own repositories 
and file issues/ feature requests.

-- Ram


-Message Disclaimer-

This e-mail message is intended only for the use of the individual or
entity to which it is addressed, and may contain information that is
privileged, confidential and exempt from disclosure under applicable law.
If you are not the intended recipient, any dissemination, distribution or
copying of this communication is strictly prohibited. If you have
received this communication in error, please notify us immediately by
reply email to conn...@principal.com and delete or destroy all copies of
the original message and attachments thereto. Email sent to or from the
Principal Financial Group or any of its member companies may be retained
as required by law or regulation.

Nothing in this message is intended to constitute an Electronic signature
for purposes of the Uniform Electronic Transactions Act (UETA) or the
Electronic Signatures in Global and National Commerce Act (E-Sign)
unless a specific statement to the contrary is included in this message.

While this communication may be used to promote or market a transaction
or an idea that is discussed in the publication, it is intended to provide
general information about the subject matter covered and is provided with
the understanding that The Principal is not rendering legal, accounting,
or tax advice. It is not a marketed opinion and may not be used to avoid
penalties under the Internal Revenue Code. You should consult with
appropriate counsel or other advisors on all matters pertaining to legal,
tax, or accounting obligations and requirements.



RE: [ANNOUNCE] svnrdump: A new dumper/ loader in trunk

2010-08-19 Thread Feldhacker, Chris
Ramkumar:
 Again, I expect that access control/ security is automatically taken care 
 of in the RA layer. `svnrdump load` is just like a user making some changes 
 and committing them one by one except the author and timestamp in the 
 dumpfile are preserved. Why would you want to block this?

A client performing a regular commit cannot currently spoof the author and 
timestamp, or can they?










-Message Disclaimer-

This e-mail message is intended only for the use of the individual or
entity to which it is addressed, and may contain information that is
privileged, confidential and exempt from disclosure under applicable law.
If you are not the intended recipient, any dissemination, distribution or
copying of this communication is strictly prohibited. If you have
received this communication in error, please notify us immediately by
reply email to conn...@principal.com and delete or destroy all copies of
the original message and attachments thereto. Email sent to or from the
Principal Financial Group or any of its member companies may be retained
as required by law or regulation.

Nothing in this message is intended to constitute an Electronic signature
for purposes of the Uniform Electronic Transactions Act (UETA) or the
Electronic Signatures in Global and National Commerce Act (E-Sign)
unless a specific statement to the contrary is included in this message.

While this communication may be used to promote or market a transaction
or an idea that is discussed in the publication, it is intended to provide
general information about the subject matter covered and is provided with
the understanding that The Principal is not rendering legal, accounting,
or tax advice. It is not a marketed opinion and may not be used to avoid
penalties under the Internal Revenue Code. You should consult with
appropriate counsel or other advisors on all matters pertaining to legal,
tax, or accounting obligations and requirements.



RE: What does Repository moved temporarily mean?

2010-05-12 Thread Feldhacker, Chris
 svn: Repository moved temporarily to 'https://[snip] please relocate

Are you going through a proxy server?
What happens if you execute the exact same command twice in a row?


We go through a proxy, and when I want to download the latest copy of Subclipse 
I issue the command:
svn export --username guest 
http://subclipse.tigris.org/svn/subclipse/trunk/www/update_1.6.x;
...and I also get the same svn: Repository moved temporarily... response.

But, if I issue the exact same command again, it works fine. (And will continue 
to work until I reboot.)
My guess would be that the proxy is sending back a response that the Subversion 
client doesn't quite know how to handle correctly...




-Message Disclaimer-

This e-mail message is intended only for the use of the individual or
entity to which it is addressed, and may contain information that is
privileged, confidential and exempt from disclosure under applicable law.
If you are not the intended recipient, any dissemination, distribution or
copying of this communication is strictly prohibited. If you have
received this communication in error, please notify us immediately by
reply email to conn...@principal.com and delete or destroy all copies of
the original message and attachments thereto. Email sent to or from the
Principal Financial Group or any of its member companies may be retained
as required by law or regulation.

Nothing in this message is intended to constitute an Electronic signature
for purposes of the Uniform Electronic Transactions Act (UETA) or the
Electronic Signatures in Global and National Commerce Act (E-Sign)
unless a specific statement to the contrary is included in this message.

While this communication may be used to promote or market a transaction
or an idea that is discussed in the publication, it is intended to provide
general information about the subject matter covered and is provided with
the understanding that The Principal is not rendering legal, accounting,
or tax advice. It is not a marketed opinion and may not be used to avoid
penalties under the Internal Revenue Code. You should consult with
appropriate counsel or other advisors on all matters pertaining to legal,
tax, or accounting obligations and requirements.



RE: LDAP Group Configuration in AuthzSVNAccessFile

2010-04-01 Thread Feldhacker, Chris
If you're willing to give up fine-grained, path-based authorization then you 
can use LDAP groups to secure access to entire repositories at the top-level.  
Just define a Location for each respository and use Apache's LDAP integration 
capabilities to secure each location with one or more LDAP groups.
http://httpd.apache.org/docs/2.2/mod/mod_authnz_ldap.html

Works fine for us!

The example below gives all authenticated users access to the Publications 
repository, but only members of the AD group SOMEAdingGroup have read-write 
access.

Location /
  AuthName Subversion Server
  AuthType Basic
  AuthBasicAuthoritative On
  AuthBasicProvider ldap

  # If ldap checks are to be used with non-ldap checks (like valid-user), set 
this to off
  AuthzLDAPAuthoritative off
  AuthLDAPURL 
ldaps://ad.company.com:3269/DC=ad,DC=company,DC=com?sAMAccountName?sub?(objectCategory=user)
  AuthLDAPBindDN CN=SOMEADMIN,OU=Users,DC=ad,DC=company,DC=com
  AuthLDAPBindPassword secret
/Location

Location /svn/Publications
  DAV svn
  SVNPath \Repositories\Publications
  SVNPathAuthz off

  # The following users/groups will have read-write permission
  Require ldap-group CN=SOMEAdminGroup,OU=Groups,DC=ad,DC=company,DC=com

  Limit GET PROPFIND OPTIONS REPORT
# For any read-only operation, allow these additional users/groups
Require valid-user
  /Limit
/Location
  

-Original Message-
From: Giulio Troccoli [mailto:giulio.trocc...@uk.linedata.com] 
Sent: Thursday, April 01, 2010 10:02 AM
To: 'Lee Kaufman'
Cc: users@subversion.apache.org
Subject: RE: LDAP Group Configuration in AuthzSVNAccessFile

 Thank you for your help but I think you may have misunderstood my 
 question.
 In your previous email where you showed the content of your 
 AuthzSVNAccessFile file as.  What I am looking for is to be able to is 
 where you say

 [groups]
 developers = Giulio Troccoli, Harpal Panesar

 I want to be able to say
 developers = CN=*,OU=Security Groups,... A group I have defined in 
 LDAP.

 The groups and user permissions are already defined for other 
 applications and services and I do not want to have to manage them in 
 LDAP and SVN.  Know of any way of doing that?


Yes, sorry, I misunderstood you. I thought you meant group as in a group in 
the access file, like the developers group I have.

No, I don't think it's possible. The only way I can think of is the script that 
Stefan already suggested.

Giulio


Linedata Services (UK) Ltd
Registered Office: Bishopsgate Court, 4-12 Norton Folgate, London, E1 6DB
Registered in England and Wales No 3027851VAT Reg No 778499447






-Message Disclaimer-

This e-mail message is intended only for the use of the individual or
entity to which it is addressed, and may contain information that is
privileged, confidential and exempt from disclosure under applicable law.
If you are not the intended recipient, any dissemination, distribution or
copying of this communication is strictly prohibited. If you have
received this communication in error, please notify us immediately by
reply email to conn...@principal.com and delete or destroy all copies of
the original message and attachments thereto. Email sent to or from the
Principal Financial Group or any of its member companies may be retained
as required by law or regulation.

Nothing in this message is intended to constitute an Electronic signature
for purposes of the Uniform Electronic Transactions Act (UETA) or the
Electronic Signatures in Global and National Commerce Act (E-Sign)
unless a specific statement to the contrary is included in this message.

While this communication may be used to promote or market a transaction
or an idea that is discussed in the publication, it is intended to provide
general information about the subject matter covered and is provided with
the understanding that The Principal is not rendering legal, accounting,
or tax advice. It is not a marketed opinion and may not be used to avoid
penalties under the Internal Revenue Code. You should consult with
appropriate counsel or other advisors on all matters pertaining to legal,
tax, or accounting obligations and requirements.