Closed Bug 466221 Opened 16 years ago Closed 15 years ago

Setup MozillaCRM staging server (after Tom gets code checked into SVN)

Categories

(mozilla.org Graveyard :: Server Operations, task)

Product:
mozilla.org Graveyard
Component:
Server Operations
Type:
task
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: jay, Assigned: oremj)

References

(
URL
)

Details

Attachments

(2 files)

Tom's ssh pubkey
393 bytes, text/plain
Details
Two DB dumps needed to stage the Mozilla CRM
318.59 KB, application/x-gzip
Details 
We will be working with Chicago Technology Coop (CTC) to develop the Mozilla CRM.  While we don't have a name for the site yet, we need to get the server setup and the SVN repo ready for development.  I suggest we go with community.mozilla.org for now.

I'll be asking Tom Wolf, CTC developer, to provide our server requirements and how he would like the server to be configured before they can start work on it.

I will will be filing bugs to get Tom and any other developers access to SVN so they can work directly through our repo and we can monitor progress and test on authstage.

General info is available at: https://wiki.mozilla.org/IT/Production_Acceptance/CRM

Stay tuned for more info in the next few days.
Suggested SVN location: /projects/mozillacrm/
The developers will be in charge of checking the code in to SVN and one of the webdev guys will be able to create the /projects/mozillacrm/ directory for you.
(In reply to comment #2)
> The developers will be in charge of checking the code in to SVN and one of the
> webdev guys will be able to create the /projects/mozillacrm/ directory for you.

Will they have access to the filesystem on the staging server?   We want to have this hosted on Mozilla servers... so that's why I logged this bug.   If we can get a vanilla Drupal + CiviCRM install setup and get it checked in to SVN, the developers can start hacking on it.

How would we handle the DB dumps?  Would they be able to access the DB as well?
The developers should be checking in Drupal/CiviCRM as part of the initial code check in.

Typically, developers do not have access to the file system or database.  If they do need access the app is probably more in the development stage then the staging stage.  If needed we can set up a development VM.
(In reply to comment #4)
> The developers should be checking in Drupal/CiviCRM as part of the initial code
> check in.
> 
> Typically, developers do not have access to the file system or database.  If
> they do need access the app is probably more in the development stage then the
> staging stage.  If needed we can set up a development VM.

Makes sense.  So do you recommend that they setup the app on their local machines, checkin to SVN, and provide you with a DB dump?   I think setting up a development VM is what we need then... I understand the difference between a staging vs development site now.

They plan to do a lot of development in the coming weeks, and we won't need to be "staged" for a demo until late Dec, early Jan.
An install profile would probably be the best way to initially set up an app, but a dump will work as well.

I'll work on setting up a dev VM.

Also, if they aren't modifying the base drupal/civicrm code it may not make
sense to check drupal/civicrm in to SVN.  In that case they will need to
provide instructions on how they want to overlay /projects/mozillacrm/ on top
of Drupal.
(In reply to comment #6)
> Also, if they aren't modifying the base drupal/civicrm code it may not make
> sense to check drupal/civicrm in to SVN.  In that case they will need to
> provide instructions on how they want to overlay /projects/mozillacrm/ on top
> of Drupal.

This first phase will not require a lot of hacking... but they will be modifying both Drupal and CiviCRM code for this project.   So I think the VM is our best approach in order to provide them with a full development environment and we will need to track changes in SVN as usual.
So we'll definitely need access to the filesystem and database during this development phase.  We can definitely check Drupal + Civi into SVN as our first step.

I think since we'll reap benefits later in the project by keeping everything in one place and because you guys already have a full development infrastructure in place, we might as well use your environment and get used to it since where the project will be ultimately living.

In terms of server details, PHP5 (5.1+ is preferred though not required), MySQL5 + webserver of choice (Drupal can work happily with just about anything, though it ships with Apache support in the form of .htaccess files) are all that are necessary.

Let me know if you need more detail on any of this!
oremj:  Do you have the info you need to get the development VM ready?  

oremj/morgamic: What is the process to get Tom access to the VM?  I am waiting for his SSH key and agreement so we can get him SVN access, but do we need to do anything else?
Attached file Tom's ssh pubkey — 
Here's my SSH pubkey.  I'm currently traveling so I'll have to send along the signed committers agreement tomorrow!
Assignee: oremj → phong
How much space do you need for this VM?
Not sure exactly how much space, but enough for developing a decent PHP based web-app with a small database of sample data.  I don't have any reference numbers to work with here.
Passing back to Jeremy.  The VM is ready.
sm-ctc01  10.2.76.69
Assignee: phong → oremj
Phong:  Is the server up and running?  Can I access the Drupal/CiviCRM site?   Just wanted to get some configuration work done while we wait for the developer's committer's agreement and LDAP account setup.

Oremj: What are the next steps to getting Tom access to the box?  Do I have access to it already?  What's the server name?
Jay: The server just have the base OS installed.
Can I get an ETA for the server being up and running?  We're running out of time and this is a Q4 goal... so hopefully we can have things ready for Tom from CTC by Monday.

I would like to get started on initial configuration of CiviCRM ASAP, so please try to have this ready soon.  Thanks!
Severity: normal → major
Attachment #350806 - Attachment mime type: application/octet-stream → text/plain
Jay, the box is up at sm-ctc01.mozilla.org.  Your username is jpatel and you do have sudo.  Since Tom doesn't have VPN access we'll probably have to bring up a public IP.  Matthew, does that sounds like the right solution?
I hope to get Tom VPN access this week (just waiting for the committer's agreement)... so if it will be easier to just wait for that, I can work on the server until he has access too.

I'm OK either way...

Oremj:  What have you installed on the server?  Is the Drupal + CiviCRM setup already?
I'm working on scrounging up a scanner.  Mine has decided to cease showing up on my box.  I'll be the office tomorrow so I'll have the agreement to you then if I can't get mine working/find a functional scanner today.
Tom should be able to log in to the box by running ssh -p 3023 twolf@63.245.208.171 

Do you need anything else for this bug?  I assumed the chicago tech guys would handle installing drupal etc.
(In reply to comment #20)
> Tom should be able to log in to the box by running ssh -p 3023
> twolf@63.245.208.171 
> 
> Do you need anything else for this bug?  I assumed the chicago tech guys would
> handle installing drupal etc.

Oh... I was hoping to have it setup, but that's fine.  I can do it myself now that I have access or wait for Tom to help me out.

I think that's it then... Thanks Phong and Oremj!
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Reopening to make sure we have all the pieces together for Tom to get to work.  Here is his email:

As I understand it, my initial SVN checkin will be Drupal + CiviCRM.  I'll set it up so that everything is ready to be checked out into a directory for the webserver to serve.  We'll need db access, of course, but any additional configuration will need to be done within the context of Drupal & Civi, so it makes sense to do that after we get the code in the repo.  Best practice is to have the Drupal and Civi databases separate, so if we're limited on the # of dbs we can use on this VM, having two would be excellent.

  On the webserver side, if it's Apache, having mod_rewrite available is nice in order to be able to do "clean URLs" in Drupal.  Otherwise, there aren't a lot of webserver settings that need tweaking.

----

So looks like we just need to have DBs setup that we can access once we checkout the code on the VM and get the site up.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(In reply to comment #20)
> Tom should be able to log in to the box by running ssh -p 3023
> twolf@63.245.208.171 

I'm seeing a prompt for a password.  I thought we were using pubkey auth?

[501] t-dub@ironsides-v2 $ ssh -p 3023 twolf@63.245.208.171
The authenticity of host '[63.245.208.171]:3023 ([63.245.208.171]:3023)' can't be established.
RSA key fingerprint is ff:35:25:70:21:ad:6c:d8:85:ca:09:09:9f:e4:68:6d.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[63.245.208.171]:3023' (RSA) to the list of known hosts.
Password:
[502] t-dub@ironsides-v2 $
Please post the output of  ssh -vv -p 3023 twolf@63.245.208.171
Oremj:  After talking with Tom, due to the delay in contract negotiations and getting the SVN access, we've decided to just let him work on this on his local machines and get the code checked into SVN when the vanilla install and initial configuration is complete.

What this means is that once Tom has the code in SVN, we just need to create a staging server for the CRM and get the DB setup.   He won't need the VM for development anymore (at least not for this first phase).

Tom:  How do you recommend we get this done?  Will you be giving us a DB dump or will we be able to setup the CRM on our staging server with an install profile or something and a clean DB?
Summary: Install Drupal + CiviCRM and get code checked into SVN → Setup MozillaCRM staging server (after Tom gets code checked into SVN)
I think the easiest thing to do is that I will get all of the code (Drupal + CiviCRM + modules + necessary configuration files, etc.) checked into SVN.  Then I'll provide a database dump for Drupal only.  That db dump can just get imported wholesale into one of the two databases on the VM and all of the code can be checked out on the VM.  I'll then need to twiddle a single line in the Drupal config and we'll have a functional Drupal install, properly configured, with all of the modules in place.

Following that, I'll run the CiviCRM installation routines on the VM (it does some configuration that relies on path information that's server-specific and is just a *pain* to migrate effectively) and supply the connection information for the second database to CiviCRM (as I mentioned previously, keeping the two databases separate is the current best practice).  From then on, we'll have a functioning instance on the development VM.  Any changes made locally will be to the code which can then be checked in and post-commit-hooked up to the VM.

If it's *easy* for me to take dumps and import dumps into the Drupal & Civi databases, I will likely use that to keep my local instance and the development instance sync-ed.  If not, I will just ensure that all relevant configuration changes that live in the dbs are accomplished via code.
oremj or mrz:  given tom's plan, what do you think will be best?  i had a few questions so i can better understand how this stuff works:

1. will we be able to host the authstage server from the VM?  
2. if not, would it be easier to just checkout the SVN code to the staging server?  
3. and will the VM be able to host the dbs or will one of you need to create the dbs and import tom's db dumps?

we really want to get something up and running by friday, so please help us get there!  thanks.
Still experiencing SSH issuse & here is the requested verbose output:

[505] t-dub@ironsides-v2 $ ssh -vv -p 3023 twolf@63.245.208.171
OpenSSH_5.1p1 Debian-3ubuntu1, OpenSSL 0.9.8g 19 Oct 2007      
debug1: Reading configuration data /etc/ssh/ssh_config         
debug1: Applying options for *                                 
debug2: ssh_connect: needpriv 0                                                                                                                                                       
debug1: Connecting to 63.245.208.171 [63.245.208.171] port 3023.                                                                                                                      
debug1: Connection established.                                                                                                                                                       
debug1: identity file /home/t-dub/.ssh/identity type -1                                                                                                                               
debug2: key_type_from_name: unknown key type '-----BEGIN'                                                                                                                             
debug2: key_type_from_name: unknown key type 'Proc-Type:'                                                                                                                             
debug2: key_type_from_name: unknown key type 'DEK-Info:'                                                                                                                              
debug2: key_type_from_name: unknown key type '-----END'                                                                                                                               
debug1: identity file /home/t-dub/.ssh/id_rsa type 1                                                                                                                                  
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048                                                                                                                     
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048                                                                                                                           
debug1: identity file /home/t-dub/.ssh/id_dsa type -1                                                                                                                                 
debug1: Remote protocol version 1.99, remote software version OpenSSH_4.5                                                                                                             
debug1: match: OpenSSH_4.5 pat OpenSSH*                                                                                                                                               
debug1: Enabling compatibility mode for protocol 2.0                                                                                                                                  
debug1: Local version string SSH-2.0-OpenSSH_5.1p1 Debian-3ubuntu1                                                                                                                    
debug2: fd 3 setting O_NONBLOCK                                                                                                                                                       
debug1: SSH2_MSG_KEXINIT sent                                                                                                                                                         
debug1: SSH2_MSG_KEXINIT received                                                                                                                                                     
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1                             
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss                                                                                                                                            
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr                                                                                                                                                                                    
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr                                                                                                                                                                                    
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96                                                  
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96                                                  
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib                                                                                                                                 
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib                                                                                                                                 
debug2: kex_parse_kexinit:                                                                                                                                                            
debug2: kex_parse_kexinit:                                                                                                                                                            
debug2: kex_parse_kexinit: first_kex_follows 0                                                                                                                                        
debug2: kex_parse_kexinit: reserved 0                                                                                                                                                 
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1                             
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss                                                                                                                                            
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr                                                                                                                                                                                    
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr                                                                                                                                                                                    
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96                                                                      
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96                                                                      
debug2: kex_parse_kexinit: none,zlib@openssh.com                                                                                                                                      
debug2: kex_parse_kexinit: none,zlib@openssh.com                                                                                                                                      
debug2: kex_parse_kexinit:                                                                                                                                                            
debug2: kex_parse_kexinit:                                                                                                                                                            
debug2: kex_parse_kexinit: first_kex_follows 0                                                                                                                                        
debug2: kex_parse_kexinit: reserved 0                                                                                                                                                 
debug2: mac_setup: found hmac-md5                                                                                                                                                     
debug1: kex: server->client aes128-cbc hmac-md5 none                                                                                                                                  
debug2: mac_setup: found hmac-md5                                                                                                                                                     
debug1: kex: client->server aes128-cbc hmac-md5 none                                                                                                                                  
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent                                                                                                                              
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP                                                                                                                                           
debug2: dh_gen_key: priv key bits set: 126/256                                                                                                                                        
debug2: bits set: 514/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '[63.245.208.171]:3023' is known and matches the RSA host key.
debug1: Found key in /home/t-dub/.ssh/known_hosts:13
debug2: bits set: 485/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/t-dub/.ssh/id_rsa (0xb8b9ca70)
debug2: key: /home/t-dub/.ssh/identity ((nil))
debug2: key: /home/t-dub/.ssh/id_dsa ((nil))
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: /home/t-dub/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Trying private key: /home/t-dub/.ssh/identity
debug1: Trying private key: /home/t-dub/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1
Password:
debug1: Authentications that can continue: publickey,keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1
Password:
debug1: Authentications that can continue: publickey,keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1
Password:
debug1: Authentications that can continue: publickey,keyboard-interactive
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey,keyboard-interactive).
[506] t-dub@ironsides-v2 $
Making this a blocker until we have Tom checking code in without issue.
Severity: major → blocker
Tom, please try again.
Same as before :

ssh -vv -p 3023 twolf@63.245.208.171
OpenSSH_5.1p1 Debian-3ubuntu1, OpenSSL 0.9.8g 19 Oct 2007      
debug1: Reading configuration data /etc/ssh/ssh_config         
debug1: Applying options for *                                                                                                                                                        
debug2: ssh_connect: needpriv 0                                                                                                                                                       
debug1: Connecting to 63.245.208.171 [63.245.208.171] port 3023.                                                                                                                      
debug1: Connection established.                                                                                                                                                       
debug1: identity file /home/t-dub/.ssh/identity type -1                                                                                                                               
debug2: key_type_from_name: unknown key type '-----BEGIN'                                                                                                                             
debug2: key_type_from_name: unknown key type 'Proc-Type:'                                                                                                                             
debug2: key_type_from_name: unknown key type 'DEK-Info:'                                                                                                                              
debug2: key_type_from_name: unknown key type '-----END'                                                                                                                               
debug1: identity file /home/t-dub/.ssh/id_rsa type 1                                                                                                                                  
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048                                                                                                                     
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048                                                                                                                           
debug1: identity file /home/t-dub/.ssh/id_dsa type -1                                                                                                                                 
debug1: Remote protocol version 1.99, remote software version OpenSSH_4.5                                                                                                             
debug1: match: OpenSSH_4.5 pat OpenSSH*                                                                                                                                               
debug1: Enabling compatibility mode for protocol 2.0                                                                                                                                  
debug1: Local version string SSH-2.0-OpenSSH_5.1p1 Debian-3ubuntu1                                                                                                                    
debug2: fd 3 setting O_NONBLOCK                                                                                                                                                       
debug1: SSH2_MSG_KEXINIT sent                                                                                                                                                         
debug1: SSH2_MSG_KEXINIT received                                                                                                                                                     
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1                             
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss                                                                                                                                            
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr                                                                                                                                                                                    
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr                                                                                                                                                                                    
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96                                                  
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96                                                  
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib                                                                                                                                 
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib                                                                                                                                 
debug2: kex_parse_kexinit:                                                                                                                                                            
debug2: kex_parse_kexinit:                                                                                                                                                            
debug2: kex_parse_kexinit: first_kex_follows 0                                                                                                                                        
debug2: kex_parse_kexinit: reserved 0                                                                                                                                                 
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1                             
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss                                                                                                                                            
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr                                                                                                                                                                                    
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr                                                                                                                                                                                    
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96                                                                      
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96                                                                      
debug2: kex_parse_kexinit: none,zlib@openssh.com                                                                                                                                      
debug2: kex_parse_kexinit: none,zlib@openssh.com                                                                                                                                      
debug2: kex_parse_kexinit:                                                                                                                                                            
debug2: kex_parse_kexinit:                                                                                                                                                            
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 133/256
debug2: bits set: 503/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '[63.245.208.171]:3023' is known and matches the RSA host key.
debug1: Found key in /home/t-dub/.ssh/known_hosts:13
debug2: bits set: 515/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/t-dub/.ssh/id_rsa (0xb90dba70)
debug2: key: /home/t-dub/.ssh/identity ((nil))
debug2: key: /home/t-dub/.ssh/id_dsa ((nil))
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: /home/t-dub/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Trying private key: /home/t-dub/.ssh/identity
debug1: Trying private key: /home/t-dub/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1
Password:
debug1: Authentications that can continue: publickey,keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1
Password:
This might be a dump question, but do we even need the VM?

Can IT checkout Tom's code from SVN (once he's got it checked in) and setup a staging server with his Drupal DB dump and a clean CiviCRM DB?

Tom:  Once the server is up, you won't need filesystem level access will you?
It might be quicker to just have Oremj help Tom get the few specific things done that he menioned in comment 26 on the staging server if he can't get SSH to the VM working.
If you don't need the vm that is fine.  Just let me know when it is checked in and provide setup instructions.
Strictly speaking we don't *need* SSH access to the VM, but it might be a bit simpler.  At least initially, though, we can probably do without.  Is there a place I should upload/email/attach the db dump when it's ready to go?
Tom: You can host the db dump and link to it here, try to attach it to the bug, or you can just email it to Jeremy directly at oremj@mozilla.com
Tom, will you please try to log in to that server again.
Success!  I am able to login to the VM with no problems now.  Thanks!
What else needs to be done to complete this bug?
Severity: blocker → normal
Oremj:  When we have a Mozilla hosted website up and running that I can use to demo the CRM, we can close this bug.  Until then, I want to keep it open to help Tom through any other issues he has after checking in the code.  

Right now, it looks like we still need to see the code in SVN and then we can sort out the webserver and DB stuff.
Is there anything I can assist with right now?  I believe Tom has access to SVN and he has sudo access on the dev VM.
(In reply to comment #41)
> Is there anything I can assist with right now?  I believe Tom has access to SVN
> and he has sudo access on the dev VM.

Not that I know of. I guess Tom or I will ping you if we need anything... we're just waiting on Tom at this point to let us know what the next steps need to be.  Sean reset his LDAP password (which he lost), so he should be good to go right now.
So I am having some SVN problems.  After trying and failing to create a /projects/mozillacrm/ directory, I noticed Aravind's comment that it was actually /projects/crm that I had rw access on.  OK, no problem.  Except that when I try to commit there I get the same error which seems to indicate that my authentication is failing:

t-dub@herman ~/moco/crm/trunk $ svn --username tom@chicagotech.org ci -m "Testing my SVN access." test.txt
svn: Commit failed (details follow):
svn: MKACTIVITY of '/!svn/act/a863d947-badb-4428-9000-6e2370c4574f': 500 Internal Server Error (http://svn.mozilla.org)

Am I doing something horribly wrong here?
(In reply to comment #43)
> t-dub@herman ~/moco/crm/trunk $ svn --username tom@chicagotech.org ci -m
> "Testing my SVN access." test.txt
> svn: Commit failed (details follow):
> svn: MKACTIVITY of '/!svn/act/a863d947-badb-4428-9000-6e2370c4574f': 500
> Internal Server Error (http://svn.mozilla.org)
> 
> Am I doing something horribly wrong here?

Yeah, you're using http:// for access... You have to use https:// or svn+ssh:// in order to commit. http:// is read-only.
(In reply to comment #41)
> Is there anything I can assist with right now?  I believe Tom has access to SVN
> and he has sudo access on the dev VM.

It looks like sudo is setup to only accept password auth, which fails since I don't have a password.
A couple of practical questions:

How do I access the VM via HTTP?  http://63.245.208.171 gives me a slickspeed test page.

Where does the code get checked out on the VM?

Where can I find the usernames/passwords for the two databases?  It'd be great if I could connect either locally from the mysql command-line utility or remotely from my machine (I'd just use my instance here; doesn't matter).  Alternately, if I had sudo access I imagine I could get into mysql as root on that box and create the databases and users myself as necessary.  I'm not sure if the plan is to use MySQL locally or if you have a separate db server or what.

Thanks!
I altered sudoers to allow you to sudo with no password.  This is your development vm, so you can check out the code anywhere you want.  MySQL, Apache, and PHP have all been installed locally.  You are welcome to configure them any way you wish.  If you have any questions you can find me(oremj) on irc.mozilla.org.
Tom:  You good to go now?  I haven't heard back from you, so hopefully you're all set to get this thing up.
That should do it.  I haven't had a chance to verify yet, but it should be good now.  I'll be looking at that later tonight.
I'm still not sure if there's external http access to this box or not, but for now I'm just tunneling over SSH to get at it.
Tom is going to use Chicagotech's dev servers.  Please reopen this bug or file a new one when the site is ready to be staged.
Status: REOPENED → RESOLVED
Closed: 16 years ago → 16 years ago
Resolution: --- → FIXED
Reopening to get things running on Mozilla servers.

Tom is wrapping up the initial work on the CRM, but CTC will no longer be actively developing it, so we need to get a few things done once Tom hands off the DB dumps and checks in the code into SVN:

1. Get the DBs (drupal and civicrm as separate from my understanding) migrated to the Mozilla DB server
2. Check out the code for the CRM on authstage and make the necessary config changes to connect to the DBs
3. Make site "public", but behind http auth

I just wanted to give webdev (oremj probably) a heads up that this is a critical bug until we have things running on our servers and find a new firm to continue the CRM development.

I am in discussions with a few people to pick up where Tom left off, so it'll be great to have this all done quickly once Tom sends us the pieces.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
What's my action on this bug right now?
Oremj:  Is there any prep work or resource allocation that needs to happen so we can move quickly once Tom hands things off?  If there isn't anything to do until we have something from Tom, I just wanted to make sure someone was aware of this coming down the pipe and ready when the time comes.
This project won't need any special resource allocation.  Please reopen when there is an action.
Status: REOPENED → RESOLVED
Closed: 16 years ago → 15 years ago
Resolution: --- → INCOMPLETE
We're finally ready to migrate the code to our internal staging server.  Here is what Tom has handed off:

1. Code is checked into SVN at http://viewvc.svn.mozilla.org/vc/projects/crm/trunk/
2. A README with notes on migration: http://viewvc.svn.mozilla.org/vc/projects/crm/trunk/sites/default/README.migration.txt?view=markup
3. Attached are 2 db dumps we need to put into our DB server

Let's work together to get the site up and running so I can review the work and we can close out our work with CTC.  Thanks.
Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---
Something is broken: 
[Fri Feb 27 10:28:15 2009] [error] [client 10.2.81.4] PHP Parse error:  syntax error, unexpected T_CONSTANT_ENCAPSED_STRING, expecting T_CASE or T_DEFAULT or '}' in /data/www/mozilla_crm.stage.mozilla.com/sites/default/modules/mozcrm/mozcrm.module on line 36
oremj:  I'm assuming you followed the steps Tom wrote in the README, right?  Any clues to why it's broken?  Any info that will help Tom work with you on this would be great.

I'll ping Tom directly, but hopefully he sees this since he's cc'd on the bug.
What is bug 479853? I'm assuming it's a Legal bug, as I can't see it, and that's the only bug type I can't see.
(In reply to comment #60)
> What is bug 479853? I'm assuming it's a Legal bug, as I can't see it, and
> that's the only bug type I can't see.

Reed: Yes, it's a legal bug. :-P Sorry.
(In reply to comment #59)
> oremj:  I'm assuming you followed the steps Tom wrote in the README, right? 
> Any clues to why it's broken?  Any info that will help Tom work with you on
> this would be great.
> 
> I'll ping Tom directly, but hopefully he sees this since he's cc'd on the bug.

I'm sorry about that; somehow the version of the code I checked in was not the latest from the mercurial repository that I was using internally.  I've checked in a fixed version of the file; it should be fine now.
I followed the instructions, but I got a lot of unauthorized messages, so I'm not sure if anything took.  You should be able to repeat the Go to http://example... part of the instructions if needed.

https://mozilla_crm.authstage.mozilla.com/
(In reply to comment #63)
> I followed the instructions, but I got a lot of unauthorized messages, so I'm
> not sure if anything took.  You should be able to repeat the Go to
> http://example... part of the instructions if needed.

Not sure what this means?  I can't get past the home page... login doesn't work, lost password does't work either.  Are the paths setup correctly in the config?  Can you provide steps for the "repeat the Go to .... if needed"?

Did you check out the latest code?  Looks like Tom checked in new code just before your last comment.  Can you try that and see if it works?

> 
> https://mozilla_crm.authstage.mozilla.com/

Tom:  Can you email me your login?  I'm assuming you're the user 0 on the site, so will be nice to have that admin access.  Also, any clues to why the site might be broken still?
Looks like staging is setup - anything else to do?
Also getting this error:  

[Wed Mar 04 14:22:57 2009] [error] [client 10.2.81.4] PHP Fatal error:  Call to undefined function timezone_identifiers_list() in /data/www/mozilla_crm.stage.mozilla.com/sites/all/modules/contrib/date/date_api.module on line 450
(In reply to comment #66)
> Also getting this error:  
> 
> [Wed Mar 04 14:22:57 2009] [error] [client 10.2.81.4] PHP Fatal error:  Call to
> undefined function timezone_identifiers_list() in
> /data/www/mozilla_crm.stage.mozilla.com/sites/all/modules/contrib/date/date_api.module
> on line 450

That's because we don't have PHP 5.2.
If you look in /admin/build/modules under the "Date" section, there should be a "Date PHP4" module listed.  Enable that and it should fix the problem.
Tom: Looks like you used a version of PHP we don't support on Mozilla staging servers... so the CiviCRM part just *can't* work:

Enabled	Name	Version	Description
incompatible	CiviCRM	2.1	Constituent Relationship Management CRM - v2.1. Allows sites to manage contacts, relationships and groups, and track contact activities, contributions, memberships and events.
This module requires PHP version 5.2.* and is incompatible with PHP version 5.1.6.
incompatible	CiviCRM OG Sync	2.2	Synchronize Organic Groups and CiviCRM Groups and ACL's. More information at: http://wiki.civicrm.org/confluence//x/nDw
This module requires PHP version 5.2.* and is incompatible with PHP version 5.1.6.

Any chance we can backport to older modules?
Oremj: What do we need to do to upgrade our staging to PHP 5.2?  Any chance we can setup an environment that will work with the CRM?
(In reply to comment #69)
> Tom: Looks like you used a version of PHP we don't support on Mozilla staging
> servers... so the CiviCRM part just *can't* work:
> 
> Any chance we can backport to older modules?

This issue isn't with the work that I've done; it's a requirement of CiviCRM.  If you want to run a modern version of CiviCRM, you'll need PHP 5.2.  A backport of Civi would be a *huge* endeavor and is not feasible.
If it requires PHP 5.2 it cannot sit next to the other production applications and will need its own VM or physical box(if the demand is high).
Oremj: It looks like we need to figure out the best solution to host this with PHP 5.2.  Would it be best to start on a VM until we're ready for public beta?  And then move to separate production server?  Or just put it on production now?  Please help us get this running somewhere that makes sense, knowing:

1. This is going to be under development for a couple of more months (at least)
2. Sometime in Q2 or Q3, we will have LOTS of people using the site, both internally and throughout the Mozilla community.

Please advise.
Upping severity since this bug is blocking a couple of critical steps in the CRM project:

1. Closing out the contract with Chicago Tech (I need to verify that things are working and evaluate how much of the work has been completed).

2. Providing Trellon (the new firm) access to the working site with progress to date so they can evaluate where we are and start working on it once the contract is signed (which will be by the end of the week). 

Mrz or Oremj:  What do you recommend we do?  Do we need to meet to discuss?  Or can we get a PHP 5.2 box setup quickly?
Severity: normal → critical
Current production servers don't support PHP 5.2, so mrz asked me to log a new bug to get a temp VM together so I can get the CRM work done to date reviewed.

Marking r.wontfix.

Will track that in bug 483891.
Status: REOPENED → RESOLVED
Closed: 15 years ago → 15 years ago
Resolution: --- → WONTFIX
I can't quite tell from the bug history -- is sm-ctc01 still in use?  Comment 46 suggests so.  But I can't tell where things went after that.
Same question for sm-crm01?
Both hosts are on an ESX server that will be turned off and re-purposed at the end of next week.  If these hosts are needed, please speak up!
sm-ctc01 was just turned off.
sm-crm01, too.
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: