Skip to Content

Changes for page Deployment-Book

Last modified by Aaron Rosenzweig on 2012/01/23 04:38
From version 11.1
edited by Pascal Robert
on 2011/05/08 23:01
Change comment: There is no comment for this version
To version 16.1
edited by Pascal Robert
on 2011/05/08 23:41
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -83,6 +83,57 @@
83 83  
84 84  It's useful to create a https configuration on your deployment-like setup. By doing that, you can try out switching between SSL and non-SSL and make sure that switching is working well. On your development box, no need to purchase a SSL certificate, you can create a self-signed certificate for free. To create a self-signed certificate on OS X, do the following:
85 85  
86 +{{code}}
87 +
88 +# sudo openssl genrsa -out /etc/apache2/localhost.key 2048
89 +
90 +# sudo openssl req -new -key /etc/apache2/localhost.key -out /etc/apache2/localhost.csr
91 +Country Name (2 letter code) [AU]: <your country code, eg: CA, US, etc.>
92 +State or Province Name (full name) [Some-State]: <full name of province or state>
93 +Locality Name (eg, city) []: <full city name>
94 +Organization Name (eg, company) [Internet Widgits Pty Ltd]: <your name>
95 +Organizational Unit Name (eg, section) []:
96 +Common Name (eg, YOUR name) []:localhost
97 +Email Address []: <your email address>
98 +
99 +# sudo openssl x509 -req -days 365 -in /etc/apache2/localhost.csr -signkey /etc/apache2/localhost.key -out /etc/apache2/localhost.crt
100 +
101 +# sudo chmod 600 /etc/apache2/localhost.key
102 +
103 +{{/code}}
104 +
105 +You know have a self-signed certificate that will be valid for 365 days. When your certificate expires, you only need to run the last command to generate a new one, no need to recreate a key or certificate request.
106 +
107 +Now, let's add that certificate to Apache configuration. Edit /etc/apache2/httpd.conf, and at the end, add:
108 +
109 +{{code}}
110 +
111 +Listen 127.0.0.1:443
112 +NameVirtualHost 127.0.0.1
113 +<VirtualHost 127.0.0.1:443>
114 +DocumentRoot "/Library/WebServer/Documents/"
115 +ServerName localhost
116 +<Directory "/Library/WebServer/Documents/">
117 +allow from all
118 +Options +Indexes
119 +</Directory>
120 +SSLEngine on
121 +SSLProtocol +SSLv3 +TLSv1
122 +SSLCertificateFile /private/etc/apache2/localhost.crt
123 +SSLCertificateKeyFile /private/etc/apache2/localhost.key
124 +</VirtualHost>
125 +
126 +{{/code}}
127 +
128 +And restart Apache:
129 +
130 +{{code}}
131 +
132 +apachectl configtest
133 +apachectl restart
134 +
135 +{{/code}}
136 +
86 86  == Deployment Components: JavaMonitor, Wotaskd and javawoservice ==
87 87  
88 88  == Setting up JavaMonitor ==
... ... @@ -104,7 +104,7 @@
104 104  
105 105  The first thing to do when an application doesn't launch by JavaMonitor/wotaskd is to launch it by command line. To do so, open a command line shell, logging as the "appserver" and start the launch script manually. For example, if you have an application named "MyApp.woa" in /Library/WebObjects/Applications, do the following commands:
106 106  
107 -* sudo --s--
158 +* sudo s
108 108  * su - appserver
109 109  * cd /Library/WebObjects/Applications/MyApp.woa
110 110  * ./MyApp
... ... @@ -119,7 +119,7 @@
119 119  
120 120  Using a continuous build system is useful. Many people in the community don't even build their applications on their development boxes anymore, they use a continuous build system to build projects from a source control repository. This is even more useful if you have more than one developer working on your projects, by centralizing builds, you can detect source merge problems, etc. You can even run unit tests and do deployments from a build system.
121 121  
122 -The most popular continuous build system is Jenkins. It's an open source project build in Java, with many useful plugins.
173 +The most popular continuous build system is Jenkins. It's an open source project build in Java, with many useful plugins.
123 123  
124 124  == Using a staging server ==
125 125