Posts Tagged Domain
Configure Chef Client on Windows to work with a proxy server, by modifying Chef Knife’s configuration file.
In my last two post, Configure Git for Windows and Vagrant on a Corporate Network and Easy Configuration of Git for Windows on a Corporate Network, I demonstrated how to configure Git for Windows and Vagrant to work properly on a corporate network with a proxy server. Modifying the .bashrc file and adding a few proxy-related environment variables worked fine for Git and Vagrant.
However, even though Chef Client also uses the Git Bash interactive shell to execute commands on Windows using Knife, Chef depends on Knife’s configuration file (knife.rb) for proxy settings. In the following example, Git and Vagrant connect to the proxy server and authenticate using the proxy-related environment variables created by the ‘proxy_on’ function (described in my last post). However, Chef’s Knife command line tool fails to return the status of the online Hosted Chef server account, because the default knife.rb file contains no proxy server settings.
For Chef to work correctly behind a proxy server, you must modify the knife.rb file, adding the necessary proxy-related settings. The good news, we can leverage the same proxy-related environment variables we already created for Git and Vagrant.
Configuring Chef Client
First, make sure you have your knife.rb file in the .chef folder, within your home directory (C:\Users\username\.chef\knife.rb’). This allows Chef to use the knife.rb file’s settings for all Chef repos on your local machine.
Next, make sure you have the following environment variables set up on your computer: USERNAME, USERDNSDOMAIN, PASSWORD, PROXY_SERVER, and PROXY_PORT. The USERNAME and USERDNSDOMAIN should already present in the system wide environment variables on Windows. If you haven’t created the PASSWORD, PROXY_SERVER, PROXY_PORT environment variables already, based on my last post, I suggest adding them to the current user environment ( Environment Variables -> User variables, shown below) as opposed to the system wide environment (Environment Variables -> System variables). You can add the User variables manually, using Windows+Pause Keys -> Advanced system settings ->Environment Variables… -> New…
Alternately, you can use the ‘SETX‘ command. See commands below. When using ‘SETX’, do not use the ‘/m’ parameter, especially when setting the PASSWORD variable. According to SETX help (‘SETX /?’), the ‘/m’ parameter specifies that the variable is set in the system wide (HKEY_LOCAL_MACHINE) environment. The default is to set the variable under the HKEY_CURRENT_USER environment (no ‘/m’). If you set your PASSWORD in the system wide environment, all user accounts on your machine could get your PASSWORD.
To see your changes with SETX, close and re-open your current command prompt window. Then, use a ‘env | grep -e PASSWORD -e PROXY’ command to view the three new environment variables.[gist https://gist.github.com/garystafford/8233123 /]
Lastly, modify your existing knife.rb file, adding the required proxy-related settings, shown below. Notice, we use the ‘HTTP_PROXY’ and ‘HTTPS_PROXY’ environment variables set by ‘proxy_on’; no need to redefine them. Since my particular network environment requires proxy authentication, I have also included the ‘http_proxy_user’, ‘http_proxy_pass’, ‘https_proxy_user’, and ‘https_proxy_pass’ settings.[gist https://gist.github.com/garystafford/8222755 /]
If your environment requires authentication and you fail to set these variables, you will see an error similar to the one shown below. Note the first line of the error. In this example, Chef cannot authenticate against the https proxy server. There is a ‘https_proxy’ setting, but no ‘https_proxy_user’ and ‘https_proxy_pass’ settings in the Knife configuration file.
Using the Code
Adding the proxy settings to the knife.rb file, Knife is able connect to the proxy server, authenticate, and complete its status check successfully. Now, Git, Vagrant, and Chef all have Internet connectivity through the proxy server, as shown below.
Why Include Authentication Settings?
Even with the domain, username and password, all included in the HTTP_PROXY and HTTPS_PROXY URIs, Chef still insists on using the ‘http_proxy_user’ and ‘http_proxy_pass’ or ‘https_proxy_user’ and ‘https_proxy_pass’ credential settings for proxy authentication. In my tests, if these settings are missing from Knife’s configuration file, Chef fails to authenticate with the proxy server.
Modified bashrc configuration for Git for Windows to work with both Git and Vagrant.
In my last post, Easy Configuration of Git for Windows on a Corporate Network, I demonstrated how to configure Git for Windows to work when switching between working on-site, working off-site through a VPN, and working totally off the corporate network. Dealing with a proxy server was the main concern. The solution worked fine for Git. However, after further testing with Vagrant using the Git Bash interactive shell, I ran into a snag. Unlike Git, Vagrant did not seem to like the standard URI, which contained ‘domain\username’:
In a corporate environment with LDAP, qualifying the username with a domain is normal, like ‘domain\username’. But, when trying to install a Vagrant plug-in with a command such as ‘vagrant plugin install vagrant-omnibus’, I received an error similar to the following (proxy details obscured):
$ vagrant plugin install vagrant-omnibus Installing the 'vagrant-omnibus' plugin. This can take a few minutes... c:/HashiCorp/Vagrant/embedded/lib/ruby/2.0.0/uri/common.rb:176: in `split': bad URI(is not URI?): http://domain\username:password@proxy:port (URI::InvalidURIError)...
After some research, it seems Vagrant’s ‘common.rb’ URI function does not like the ‘domain\username’ format of the original URI. To fix this problem, I modified the original ‘proxy_on’ function, removing the DOMAIN environment variable. I now suggest using the fully qualified domain name (FQDN) of the proxy server. So, instead of ‘my_proxy’, it would be ‘my_proxy.domain.tld’. The acronym ‘tld’ stands for the top-level domain (tld). Although .com is the most common one, there are over 300 top-level domains, so I don’t want assume yours is ‘.com’. The new proxy URI is as follows:
Although all environments have different characteristics, I have found this change to work, with both Git and Vagrant, in my own environment. After making this change, I was able to install plug-ins and do other similar functions with Vagrant, using the Git Bash interactive shell.
$ vagrant plugin install vagrant-omnibus Installing the 'vagrant-omnibus' plugin. This can take a few minutes... Installed the plugin 'vagrant-omnibus (1.2.1)'!
Change to Environment Variables
One change you will notice compared to my last post, and unrelated to the Vagrant domain issue, is a change to PASSWORD, PROXY_SERVER, and PROXY_PORT environment variables. In the last post, I created and exported the PASSWORD, PROXY_SERVER, and PROXY_PORT environment variables within the ‘proxy_on’ function. After further consideration, I permanently moved them to Environment Variables -> User variables. I felt this was a better solution, especially for my password. Instead of my user’s account password residing in the .bashrc file, in plain text, it’s now in my user’s environment variables. Although still not ideal, I felt my password was slightly more secure. Also, since my proxy server address rarely change when I am at work or on the VPN, I felt moving these was easier and cleaner than placing them into the .bashrc file.
The New Code
Install WebLogic Server 12c on Windows, create a new domain, and deploy a sample application, all in 30 minutes or less! A quick overview of the entire process, installation to deployment.
Installing Oracle WebLogic Server 12c on Windows
Oracle has made the installation and setup of WebLogic Server 12c on Windows, remarkably easy for us as developers. In less than a half-hour, you can install WebLogic Server, create a new WLS domain, configure the new WebLogic Server domain in NetBeans, and deploy your first application. In this post, we will run through the most basic example of the install and configuration process.
In an actual production environments, even on your development machine, you will have added considerations when deploying high-performance enterprise applications and services to WebLogic Server. Considerations, such as security, persistence, web service configuration, performance, monitoring, and messaging, not be covered. None the less, this post should show just how easy it is to get started with WebLogic Server.
In this brief post, we will cover :
- Installing Logic Server 12c on Windows
- Creating a New WebLogic Server Domain
- Accessing the New WebLogic Server Domain
- Creating a Sample Project to Deploy to Domain
- Deploying the Sample Project
Installing WebLogic Server 12c
Download the latest version of WebLogic Server (WLS) from Oracle’s website. Once the rather large download is complete, double-click on the executable file to start the install process. I used all the default settings during the installation, illustrated below.
Oracle recommends you create a %MW_HOME% environmental variable, whose value is the Middleware Home Directory, shown in the screen-grab, below:
Note the WebLogic Server Product Installation Directory in the screen-grab, below. You will need it for other configuration later in the post. You might also consider creating a %WL_HOME% environmental variable to store this value. It saves time when executing WLS commands in the terminal:
If you exit the Quick Start utility, and wish to return to it later, you can run the following command script:
Creating a New WebLogic Server Domain
With WLS installed, the first thing you will want to do is create a new WebLogic Server domain to host your applications. The easiest way to create a domain is the Fusion Middleware Configuration Wizard. To start the Wizard, run the following command script (there is also an executable in the same directory):
The following screen-grabs show the creation a basic domain using the Wizard, without any added feature and functionality, such as web services, messaging, or persistence.
Make sure to note the username, password, and port you choose during the set-up. You will need them later to start the domain and to deploy to it.
Accessing the New WebLogic Server Domain
To start the new domain, run the following command script:
Once started, to reach the domain’s Administration Console, open a browser and enter the following URL (adjust it for the port you chose earlier):
Log into WLS using the username and password you chose during the domain creation in the previous steps.
Configuring WebLogic Server in NetBeans
Open NetBeans and switch to the ‘Services’ Tab, right-click on ‘Server’, and select ‘Add Server…’. Enter the values used during the installation and domain creation steps, above.
The ‘Server Location’ will be the same value as our %WL_HOME% variable:
The ‘Domain’ path will the root of our new domain, located where all domains are, in the ‘domains’ directory:
Creating a Sample Project to Deploy to Domain
To test your new WLS domain, create a quick Java EE Hello World RESTful web service NetBeans sample project. We have used this sample many times before in previous posts to demonstrate various server deployments.
Right-click on the project, and select ‘Properties’, and then select the ‘Build’ -> ‘Run’ menu item. Change the Server to ‘Oracle WebLogic Server’. Leave all the other options with their default values.
Deploying the Sample Project
Right click on the Apache Ant ‘build.xml’ file on the ‘Files’ tab. Select ‘Run Target’ -> ‘Other Targets’ -> ‘run-deploy’. Apache Ant will run the run-deploy target, which will run a series of dependent targets. They will compile the project, build the .war file, and deploy the .war to the newly created WLS domain. Since we did not configure any additional server within the domain, the project will be deployed to the existing ‘AdminServer’ server.
Return to the Administrative Console, and switch to the ‘Deployments’ window to view the newly deployed project.
To view the deployed project, open a second web browser window and enter the following URL:
There you have it, a whirlwind WebLogic Server installation to deployment demonstration. So, how long did it take you?