I'm routing to the AMS team. I think they have an idea on how to help. Best Regards, Matthew Mosesohn

I'm happy to "own" the maintenance of this server... at least as far as I can. But bear in mind I'm not co-located where the server is, nor do I have physical access to it. > So really the best approach here is IMHO to have a defined process for me to make simple tech support requests of the IT personnel who do have root access to this box. The last time we had a problem, the server had run out of space - not something I could fix with my limited sftp access. This time the issue is .htaccess file updates. I can put the files myself on the wallace server, but I cannot guarantee they'll arrive on devstudio.jboss.com; if your rsync rule excludes .dotfiles, I'm stuck filing helpdesk tickets like this one. :)

I would recommend that we turn on overrides on that directory for authentication and authorization configurations. Then you will be able to create .htaccess files and control access through that. Would that be acceptable to you?

If by "that directory" you mean nboldt@wallace.redhat.com:/mnt/devstudio/, then by all means. If I can push changes to these dirs myself, then I need not inconvenience you guys, and everyone wins. :) Can you guarantee that changes I make to the .htaccess files in that folder (and its children) will be synched to http(s)://devstudio.jboss.com/ (and its children) ?

The directory on wallace is synced out to the datacenter and served from the proxies as is. Thus, when you add .htaccess files on wallace, it should take effect on the proxies after a short delay. I will put the change request in to make this happen. But we won't be able to enable it till after March 10th due to the End of Quarter Freeze. Will this work for you? If not we can seek approval from the CIO. Thanks.

When *can* it be enabled, if not by March 10? A week later? April 1? Alternatively, how long would CIO approval take?

It could be done by the Monday of the next week (March 15th) with out any problems. If you need it before then we could look into completing it on March 11th. CIO approval can happen as business needs dictate. Basically if you need it done before March 11th, let me know when you need it by and I'll let you know what will be needed on your part. Contact with your organization's IT Relationship Manager will be needed at a minimum for a EOQ Freeze change.

Mar 15 is fine. Thanks!

reconfigure .htaccess rules for devstudio.jboss.com --------------------------------------------------- Key: JBDS-1110 URL: https://jira.jboss.org/jira/browse/JBDS-1110 Project: Developer Studio (JBoss Developer Studio) Issue Type: Task Components: updatesite Affects Versions: 3.0.0.CR3 Reporter: Nick Boldt Assignee: prakash aradhya Priority: Critical Fix For: 3.0.1.GA Problem ----------- Currently we host update site files and some Early Access (EA) JBoss Dev Studio (JBDS) installers (.jar) on http(s)://devstudio.jboss.com. Everyone using the site shares the same access, which is somewhat painful for several reasons: a) No one can "discover" what's on the site because the root folder is restricted. b) EA users and existing registered JBDS users may not be the same folks; in fact, we may want to provide *FREE* EA access to encourage people to try-before-buy the forthcoming JBDS release, independent of possibly being an existing subscriber. c) Each annual release of JBDS gets a year of updates, but only for the product for which they subscribed; thus each year's update site should be differently restricted rather than using the shared across-the-board login. Ideally, username/password restriction would be fed by information in the CSP so that users would only need a single login, which would expire the minute their subscription expired, rather than using shared passwords via .htaccess; however, that requires significantly (?) more effort than the solution proposed below. Solution ----------- a) remove .htaccess username/password restriction for these folders: http://devstudio.jboss.com/ http://devstudio.jboss.com/updates/ http://devstudio.jboss.com/earlyaccess/ b) add .htaccess username/password restriction for these folders: http://devstudio.jboss.com/updates/2.1/ (use existing username/password) http://devstudio.jboss.com/updates/3.0/ (create new username/password) http://devstudio.jboss.com/earlyaccess/builds/ (use existing username/password + create second new username/password) I will send the current login details & proposed new ones along in an email to helpdesk@ so that they're not copied publicly here. Note that JBDS 3.0 is scheduled to be released March 10, and we need to get these changes in place before then.