Skip to Content

Changes for page Deployment-Book

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

Summary

Details

Page properties
Content
... ... @@ -83,57 +83,6 @@
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 -
137 137  == Deployment Components: JavaMonitor, Wotaskd and javawoservice ==
138 138  
139 139  == Setting up JavaMonitor ==
... ... @@ -155,7 +155,7 @@
155 155  
156 156  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:
157 157  
158 -* sudo s
107 +* sudo --s--
159 159  * su - appserver
160 160  * cd /Library/WebObjects/Applications/MyApp.woa
161 161  * ./MyApp
... ... @@ -170,7 +170,7 @@
170 170  
171 171  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.
172 172  
173 -The most popular continuous build system is Jenkins. It's an open source project build in Java, with many useful plugins.
122 +The most popular continuous build system is Jenkins. It's an open source project build in Java, with many useful plugins.
174 174  
175 175  == Using a staging server ==
176 176