Closed (fixed)
Project:
Drupal.org infrastructure
Component:
Servers
Priority:
Normal
Category:
Task
Assigned:
Reporter:
Created:
23 May 2011 at 14:13 UTC
Updated:
21 Aug 2014 at 21:00 UTC
Jump to comment: Most recent
We want to use it for the Prairie initiative http://groups.drupal.org/prairie-initiative
Such big plans and great mockups. But if we do not start implementing, this is dragging...
Don't know if there are some Dev Environments that we can re-use. But of course we are happy to use a brandnew one :)
Comments
Comment #1
drummCreated, I named it prairie.
Comment #2
eigentor commentedThx. I can connect via SSH.
I get a "Notice to users" from the Oregon State University with three paragraphs of text.
If I read the document http://drupal.org/node/1018084 right, I should read the document "comment".
Alas, it asks me for a password before I can do anything. This password does not appear to be the one of my d.o. account.
Comment #3
eigentor commentedAh, got it. Can read everything now.
Comment #4
drummAccess is only by SSH key, I used your key at http://drupal.org/user/96718/ssh-keys
Comment #5
drummComment #6
eigentor commentedAs this dev environment has no version control and only ssh access, we thought about setting up a dev environment with git on our server, because we could work on it much better.
This would be protected by general standards and a .htaccess of course (the hoster is specialized in Drupal hosting http://www.drupalconcept.de/)
But I got a bit of a pain in the stomach about security implications, as d.o. may be much better protected than our server, so people might get to the code in the worst case. And you generally may not want the code to be in any other place than the dev environment you set up for us.
So I thought I better ask what you think about that.
Comment #7
drummLike any Drupal site, Drupal.org is just a bunch of contrib modules and some custom code. Modules need git patches, you can swap in git checkouts on modules you are working on. BZR does allow local branches, if you want to do that for the theme, but do post full patches against trunk to http://drupal.org/project/bluecheese.
We have made every effort to sanitize the site so even in development environments on our server, personal information is not exposed. But, setting up servers with the amount of data Drupal.org has, and dependencies, is a lot of work. I've found the development environments to be more convenient than futzing around with sysadmining random boxes.
Comment #8
eigentor commentedWe will probably do a bit more than work on the theme.
Putting into reality stuff like the planned topic pages: http://groups.drupal.org/node/144584 will require quite some fiddling.
We have heard and are fully aware of that any use of a new module or other coding has quite high barriers to overcome, and know that we need to post patches, discuss and everything.
You told me on IRC to keep patches small and I will. Having gone down the road of core patches one gets to know the processes. :)
Still we want to do a full proof of concept.
Working with several people only through ssh and no versioning is a drag for real work.
So this was my real question: do you object to us using the data from prairie-drupal.redesign.devdrupal.org setting up a version controlled and convenient dev environment somewhere else?
I would fully understand if you do, then we can get on with the current dev environments at staging.drupal.org
Maybe some time in the future the dev environments can be repositories so people can collaborate on it more easily.
I know this is a lot to ask but in order to boost participation on improving d.o. it would definitely help.
Comment #9
eigentor commentedAlrighty, Derek Wright convinced us not to use any additional remote machine. We will try how far we get with this and bzr read access to keep in sync with the current d.o.
http://drupal.org/node/1171210
Comment #10
drummThe general idea is to take on doable chunks of work and use separate development environments for each. Building lots of dependencies between projects is a drag too, and contributed to the big Drupal.org redesign taking so long. With short, doable projects, that get done, newer projects always get fresh development environments. The general idea is that configuration management and everything isn't there yet in Drupal, so we are concentrating on getting fresh copies of what the live site really is doing.
Just because BZR isn't Git, doesn't mean it isn't a great version control system, it just isn't git. You can branch locally and do a whole distributed workflow. I haven't opted to use that personally, since changes are so short-lived before getting into drupalorg's or another module's Git repository. I could imagine checking changes into each dev site locally, and merging into the central prairie site. But, that won't solve configuration not covered by features, and could get cumbersome to maintain. Data on dev sites gets stale quickly.
Comment #12
eigentor commentedTried bzr checkout and got a Permission denied public key.
Please grant me pull access for the bazaar repo.
Comment #13
eigentor commentedComment #14
drummI granted BZR read-only access via our old process at http://drupal.org/node/1018070. (Hopefully it is right, has been awhile since I've used that.)
Remember, BZR is more of a deployment management for us. Everything, except the theme, goes through contrib, like http://drupal.org/project/drupalorg. I'll even get changes to multiple projects out of a BZR diff myself, if I want to see something deployed. Please actually try out some code/configuration changes with something that is straightforward enough to be reviewed and deployed.
Comment #15
eigentor commentedO.K. the bazaar checkout worked, and after learning how to import this ginormous Database, I got d.o. on my local machine up and running!
One thing though: The database that comes with it does not seem to be thorougly sanitized. It has got all the e-Mail adresses of the users in it. I guess this should not be that way?
It has all password hashes as well - I guess if I could reverse-engineer MD5 hashes I could do a lot of bad stuff now...
Comment #16
gregglesWhere did you get the database?
Feel free to find me in irc to discuss.
Comment #17
gregglesp.s. you can checkout bzr+ssh://eigentor@util.drupal.org/bzr/scripts/ and then run drupal-sanitize-dump.sql and then drupal-reduce-dump.sql which should sanitize your local copy. And then delete the file you downloaded.
Comment #18
drummI removed the files http://drupal.org/node/1018070 instructed to use, and disabled the Jenkins build to make more. That DB snapshot should have been turned off when the redesign was launched. Please remove those files.
Please try using the development environment, http://drupal.org/node/1018084.
Comment #19
drummUPDATE users SET mail = CONCAT(name, '@localhost'), init = CONCAT('http://drupal.org/user/', uid, '/edit');Will remove emails.Comment #20
eigentor commentedI will remove the personal data from my snapshot. I just wanted ato alert you of all the info being in and maybe getting into the wrong hands.
Comment #21
drummNothing else needs to happen for this issue, correct?
Comment #22
eigentor commentedyeah. If we really start to work on the site one day I might request to reset it to match current d.o., but can open a fresh issue for that.
Comment #24
drummI destroyed this dev site since it hasn't been accessed since June, and we need the space. Please reopen if an issue or project needs space to work on implementation.